Hello everyone,
I have a very simple program for the process, but it's driving me crazy and I can't see the problems I'm left with:
Short topological description:
Dual Core Berghof controller with softmotion runtime version 3.5.19.30;
Two axes with servodrive on canopen bus, clocked distributed from master;
Ethercat I/O node;
2 ms ethercat task, 2 ms canopen bus cycle time;
I/O objects of the canopen master and canopen drives connected to the ethercat task cycle;
Problem 1: Two separate programs each manage their own axis and drive, with separate state machines. A first axis moves primarily in velocity, except having to position itself absolutely at a predetermined point at the end of the job; the second axis, on the other hand, is a paper unwinder that changes, for each job cycle, from actions in absolute, relative, and cam displacement with the master axis.
Well, the state machine of both axes was written in such a way as to call running the useful FB and change it on state change in this way:
The code above is a sketchy example of what I wanted to write. But it gives me a spot problem: in some, the state change results in a drive error, which is unrecoverable except with a reinitialization via SM3_ReinitDrive().
Things are improved a little if in the program I always run the call of all softmotion blocks in this way:
If I don't execute all the calls of all the motion FBs used, when exchanging machine state often (but not always), the axis goes into error with event id THE_FB_WASNT_CALL... Done a little diagnostics it seems that the FBs return the bDone, before they are completely terminated. I tried doing the machine state exchange not with the bDone bit of the FBs, but with the 'standstill' state of the axis. It didn't seem to change anything.
Problem 2:
During the use SM3_ReinitDrive() I get the erro in the log: "NetID 0: SDO read error for object 16#607C..."
Assuming that the device involved it's one of the two servodrive, (no others device are present in the network), I don't found any object 0x607C in the 'possible object list in/out' of the two drive, and I don't understand where this object can be listed.
So any ideas and suggestions regarding these two issues will be very, very welcome. If you need the source project, I am willing to send it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose that you are referring to the error code "SMC_FB_WASNT_CALLED_DURING_MOTION"?
Starting of Softmotion version 4.15.0.0 the instance path of the function block that has not been called is logged into the device log. This might help you to identify why it has not been called.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this is the error the sometimes show up.
What make me crazy is the fact that it happens randomly and not each times. I know very well where the problem is, in wich one program row it's located. For each actions of the state machine I have all events recorded with log on text file. it is not problematic for me to find the application point of the fault, but I need to understand why occasionally and for no apparent reason, switching the state machine and thus changing the motion FB, sends the axis into failure (but only occasionally).
For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state.
Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
In general:
- Motion function blocks have to be called until they report 'Done', 'Error', 'CommandAborted' or a subsequent motion FB with BufferMode=Aborting is started in the current cycle.
- Setting the Execute input to FALSE will not abort any ongoing motion of the motion function block.
For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state.
I think the error SMC_FB_WASNT_CALLED_DURING_MOTION is only a follow-up (and misleading) error that results from the axis not being in operational state anymore (bus problems). Is there an error 'regulator or start not set' in the device log before the error 'motion generating FB wasn't called for at least one cycle'? Which error does the respective function block (Halt.ErrorId) report?
👍
1
Last edit: tk096 2024-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your interest. Your answers are in line with what I knew, so at least it comforts me that I did not misinterpret the situation. However, I don't have an exact match as, for this project over the past few days I have:
1) I have gone back to leaving the various FBs of the motion always called, all of them, and in the state machine I use a boolean to activate the various useful Execute. (But in the future I want to go back and try the programming technique with which I wanted to develop this project);
2) For the occasional error: SMC_FB_WASNT_CALLED_DURING_MOTION perhaps it was due to the fact that I had set the Ethercat bus synchronism only at the CAN master level, but not at the level of individual drives. I have now also activated it for the individual drives and it does indeed seem to have been resolved, but having also adopted the programming technique mentioned in point 1), I cannot say whether this was the solution to the problem, or instead the previous point.
Is there an error ‘regulator or start not set’ in the device log before the error ‘motion generating FB wasn't called for at least one cycle’?
I can't answer that right now. By now the machine is running and I am no longer there, at this one. Also, I seem to remember that the 'fbeFBerror' drive structure (5-element array), does not cycle, BUT ONCE THE 5 EVENTS AFTER SWITCHING ON, IT DOES NOT UPDATE ANYMORE (but that's another issue), so diagnostics were not easy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this point is part of my misunderstanding. Why, after the execution ot the motion FBs is set to FALSE and exsecuted at lest one time, it must be continuosly called, even if the motion control it's take from another subsequent instruction. This is what I really don't undertand, but what in fact it's happening.
For example, in case of stopping a MoveVelocity FB, then Halting the motion by the related FB, the axis at spot goes into error. If there was bad trigger management, the various instructions would NEVER work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone,
I have a very simple program for the process, but it's driving me crazy and I can't see the problems I'm left with:
Short topological description:
Dual Core Berghof controller with softmotion runtime version 3.5.19.30;
Two axes with servodrive on canopen bus, clocked distributed from master;
Ethercat I/O node;
2 ms ethercat task, 2 ms canopen bus cycle time;
I/O objects of the canopen master and canopen drives connected to the ethercat task cycle;
Problem 1: Two separate programs each manage their own axis and drive, with separate state machines. A first axis moves primarily in velocity, except having to position itself absolutely at a predetermined point at the end of the job; the second axis, on the other hand, is a paper unwinder that changes, for each job cycle, from actions in absolute, relative, and cam displacement with the master axis.
Well, the state machine of both axes was written in such a way as to call running the useful FB and change it on state change in this way:
The code above is a sketchy example of what I wanted to write. But it gives me a spot problem: in some, the state change results in a drive error, which is unrecoverable except with a reinitialization via SM3_ReinitDrive().
Things are improved a little if in the program I always run the call of all softmotion blocks in this way:
If I don't execute all the calls of all the motion FBs used, when exchanging machine state often (but not always), the axis goes into error with event id THE_FB_WASNT_CALL... Done a little diagnostics it seems that the FBs return the bDone, before they are completely terminated. I tried doing the machine state exchange not with the bDone bit of the FBs, but with the 'standstill' state of the axis. It didn't seem to change anything.
Problem 2:
During the use SM3_ReinitDrive() I get the erro in the log: "NetID 0: SDO read error for object 16#607C..."
Assuming that the device involved it's one of the two servodrive, (no others device are present in the network), I don't found any object 0x607C in the 'possible object list in/out' of the two drive, and I don't understand where this object can be listed.
So any ideas and suggestions regarding these two issues will be very, very welcome. If you need the source project, I am willing to send it.
Hi,
I suppose that you are referring to the error code "SMC_FB_WASNT_CALLED_DURING_MOTION"?
Starting of Softmotion version 4.15.0.0 the instance path of the function block that has not been called is logged into the device log. This might help you to identify why it has not been called.
Yes, this is the error the sometimes show up.
What make me crazy is the fact that it happens randomly and not each times. I know very well where the problem is, in wich one program row it's located. For each actions of the state machine I have all events recorded with log on text file. it is not problematic for me to find the application point of the fault, but I need to understand why occasionally and for no apparent reason, switching the state machine and thus changing the motion FB, sends the axis into failure (but only occasionally).
For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state.
Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
In general:
- Motion function blocks have to be called until they report 'Done', 'Error', 'CommandAborted' or a subsequent motion FB with BufferMode=Aborting is started in the current cycle.
- Setting the Execute input to FALSE will not abort any ongoing motion of the motion function block.
I think the error SMC_FB_WASNT_CALLED_DURING_MOTION is only a follow-up (and misleading) error that results from the axis not being in operational state anymore (bus problems). Is there an error 'regulator or start not set' in the device log before the error 'motion generating FB wasn't called for at least one cycle'? Which error does the respective function block (Halt.ErrorId) report?
Last edit: tk096 2024-07-22
Thank you for your interest. Your answers are in line with what I knew, so at least it comforts me that I did not misinterpret the situation. However, I don't have an exact match as, for this project over the past few days I have:
1) I have gone back to leaving the various FBs of the motion always called, all of them, and in the state machine I use a boolean to activate the various useful Execute. (But in the future I want to go back and try the programming technique with which I wanted to develop this project);
2) For the occasional error: SMC_FB_WASNT_CALLED_DURING_MOTION perhaps it was due to the fact that I had set the Ethercat bus synchronism only at the CAN master level, but not at the level of individual drives. I have now also activated it for the individual drives and it does indeed seem to have been resolved, but having also adopted the programming technique mentioned in point 1), I cannot say whether this was the solution to the problem, or instead the previous point.
I can't answer that right now. By now the machine is running and I am no longer there, at this one. Also, I seem to remember that the 'fbeFBerror' drive structure (5-element array), does not cycle, BUT ONCE THE 5 EVENTS AFTER SWITCHING ON, IT DOES NOT UPDATE ANYMORE (but that's another issue), so diagnostics were not easy.
Most FBs clock on the rising edge so if they are never called with xExecute = False then subsequent actions will not be performed.
Maybe the example posted it's not so clear, but this is not the problem. The execution of every motion methods is well triggered.
I was answering your last paragraph
Yes, this point is part of my misunderstanding. Why, after the execution ot the motion FBs is set to FALSE and exsecuted at lest one time, it must be continuosly called, even if the motion control it's take from another subsequent instruction. This is what I really don't undertand, but what in fact it's happening.
For example, in case of stopping a MoveVelocity FB, then Halting the motion by the related FB, the axis at spot goes into error. If there was bad trigger management, the various instructions would NEVER work.