writing too fast to canopen or motors?

[acisre]

Hi all,

 

Right now, I am working on a program where I need to write instructions via canopen to several different motors and pneumatic cylinders.

Please see attached image for better explanation.

 

at the start of each rung, I am using a comparator (see green circle). Only if my variable has the correct value, the rung can be accessed.  Then everything in that rung gets executed, and the counter now is increased by 1 (blue circle), so on the next plc scan I can access the next rung.

This works well, but its here where the problems start. During 1 plc scan, several instructions are written to the motors and drivers (mac95 motor from JVL, MIS234 motor from JVL, SMC75 drivers...)

It seems that these instructions are written so fast, that some instructions get ignored by the motors. Thus nothing works as it should. This is why a timer and system bit was added (orange circle), to give the motor some time at the start of each rung. It now works, as long as I keep the timer around 40 ms. Any value lower than that and the motors seem to miss instructions from time to time.

The problem with this is that I loose some time when writing several instructions like new motor speed, new motor position, motor mode, etc... For example 5 instuctions like that costs me 200 ms of time that the machine is doing nothing. That isn't much, but cycle time is of crucial importance so I'm looking for ways to avoid the use of these delay timers.

What I can say is that, using only system bits without the timers (to check if the motor buffer isn't full) doesn't work as well. I seem to loose instructions even when the motor buffer isn't full yet). 

 

I also contacted JVL about this issue, they basically told me to (quote):

Quote

 

If you use the newest version of firmware and still have this problem, I think you should disconnect all motors except one and then make a test with that.

You should try with both SMC75 and with MAC095 and see if there are any difference.

If one is working better then try to connect one more of the same type and see what happens.

And also if you take one of each type ( 2 motors ).

 

 

This is a lot of work for me and so I was wondering If anyone on this forum has some tips or a similar experience on how to avoid the use of timers without losing instructions when writing to the motor.

 

Thank you

 

Sven

[kratmel]

Hi, Sven

As i see you use SDO for motor control.

I use SDO for transmit motion profile parameter for 2 lenze drive.

I also lose instructions when try writing to the motor by the timer.

For implement SDO transmition without timer i used SDO numbering like compare counter in you code.

Please see attachment.  
I must send comand to change speed and position for two station. If i send 1-st command - all another sdo sended one by one with no problem and sdo transmition stopped. Rewriting the same information by SDO in my system is no problem. And it will be avoided by the additional code.

If i send #8 command only one sdo sended and transmision stopped.

This sample code posted only like idea for sequental SDO transmission. Only one SDO sended at the same time and no command lost present in my system.

Maybe code not optimised, but it work fine in real control system.

 

 

 

SDO_test_lenze.vlp

[Isakovic]

It seems to me that this happened:

Rung 6 gets executed because stage index in 3, at the end of the rung index is incremented to 4 so the next rung 7 also gets executed. When you say some messages are ignored, is it that only the last message gets through?

[acisre]

10 hours ago, kratmel said:

Hi, Sven

As i see you use SDO for motor control.

I use SDO for transmit motion profile parameter for 2 lenze drive.

I also lose instructions when try writing to the motor by the timer.

For implement SDO transmition without timer i used SDO numbering like compare counter in you code.

Please see attachment.  
I must send comand to change speed and position for two station. If i send 1-st command - all another sdo sended one by one with no problem and sdo transmition stopped. Rewriting the same information by SDO in my system is no problem. And it will be avoided by the additional code.

If i send #8 command only one sdo sended and transmision stopped.

This sample code posted only like idea for sequental SDO transmission. Only one SDO sended at the same time and no command lost present in my system.

Maybe code not optimised, but it work fine in real control system.

 

 

 

SDO_test_lenze.vlp

Thank you very much I will definitely take a look at it! 

 

7 hours ago, Isakovic said:

It seems to me that this happened:

Rung 6 gets executed because stage index in 3, at the end of the rung index is incremented to 4 so the next rung 7 also gets executed. When you say some messages are ignored, is it that only the last message gets through?

No when rung 6 is executed, this rung also resets the timer. The next rung 7 will not be executed because the PLC is so fast that by that time the timer is still running and the timer bit is still zero... Only after a minimum of (in the screenshot) 20 ms rung 7 will be executed.

[acisre]

@kratmel I looked at the code and it does look good. I like how the counter is at the top row, so its not needed to put the increment block in every rung. I will see if I can use it in my program.

 

I do have another question though: if I would leave out the timers in my program, I wonder what happens. Is every rung executed in one PLC scan? Or does he do the increment function at the end of every scan? In other words, if I would have 50 rungs, would all these rungs be executed in a single scan, or would it take 50 scans before every rung is executed? (thsi was also what Isakovic was thinking I guess)

Because if it would be the first case (everyting in one scan) then it's probably normal I'm using instructions. However, if it takes multiple scans, then in theory it should work I think.

 

Or same question with a simple program (see attached screenshot): at the end of one PLC scan, what is the value of MI 1? (I would test it but cannot do the online test right now)

 

[Flex727]

1 hour ago, acisre said:

at the end of one PLC scan, what is the value of MI 1?

The value would be 2. 

1 hour ago, acisre said:

Is every rung executed in one PLC scan?

This is a fundamental property of PLCs running ladder logic. The basic order of operations is:

1) Read inputs

2) Execute all ladder logic

3) Write outputs

Repeat.

This is simplified, and leaves out networking, HMI updates, and analog (and certain other I/O), but this should be fully understood by any PLC programmer.

On 8/14/2018 at 7:48 AM, acisre said:

The next rung 7 will not be executed because the PLC is so fast...

No, it's because all ladder rungs are executed before it gets back around to re-evaluating the timer coil.

[acisre]

2 minutes ago, Flex727 said:

The value would be 2. 

I don't understand this...

If you say that all outputs are changed/written  only at the end of the PLC scan, then I would think it goes like this:

• first scan, 0 is stored in MI 1
• end of first scan --> 0 written to MI 1
• second scan, second rung gets executed and MI 1 is increased by 1
• end of second scan --> 1 written to MI 1
• third scan, third rung gets executed and MI 1 is increased by 1
• end of third scan --> 2 written to MI 1

So I would not expect MI 1 to be 2 in just 1 scan?

[sgull]

Hi Acisre

The PLC will evaluate all the code with each scan.

I think the way the code is written it would be impossible to know what MI-1 will be.

If you use a positive transition contact for the increment the value would be 2.

With a direct contact of the compare the value will increment continuously for the scan time.

[Flex727]

2 hours ago, acisre said:

I don't understand this...

"Outputs" means the digital outputs that are operands that begin with O. Integer operands, such as MI 1, are not outputs.

[Flex727]

42 minutes ago, sgull said:

I think the way the code is written it would be impossible to know what MI-1 will be.

If you use a positive transition contact for the increment the value would be 2.

With a direct contact of the compare the value will increment continuously for the scan time.

This is not true. MI 1 is reset to zero at the beginning of each scan, then it is incremented twice. The value will be 2, and it will stay at 2. The outside world will never see any other value for MI 1 except 2.

[Flex727]

8 minutes ago, Flex727 said:

"Outputs" means the digital outputs that are operands that begin with O. Integer operands, such as MI 1, are not outputs.

I just realized this is a bit ambiguous. The "O" operand itself will be updated immediately when it appears as a coil. When I say Write Outputs, I mean when the output module itself (the physical hardware) will be written to (thus actually sending the signal to the outside world).

[Flex727]

2 hours ago, acisre said:

If you say that all outputs are changed/written  only at the end of the PLC scan, then I would think it goes like this:

• first scan, 0 is stored in MI 1
• end of first scan --> 0 written to MI 1
• second scan, second rung gets executed and MI 1 is increased by 1
• end of second scan --> 1 written to MI 1
• third scan, third rung gets executed and MI 1 is increased by 1
• end of third scan --> 2 written to MI 1

Let me see if I can explain this a bit more clearly. The MI is a memory location. It doesn't get "written to" in the sense I was referring above when talking about PLC order of operations.

- First rung is evaluated, zero is stored in MI 1

- Second rung is evaluated, the value in MI 1 (currently zero) is compared to zero. It is true, therefore MI 1 is incremented. It is now 1.

- Third rung is evaluated, the value in MI 1  (currently 1) is compared to 1. It is true, therefore MI 1 is incremented. It is now 2.

The ladder is now complete and the outside world can now see that the value of MI 1 is 2.

Then we return to the first rung and start all over again with the same result.

[acisre]

23 minutes ago, Flex727 said:

Let me see if I can explain this a bit more clearly. The MI is a memory location. It doesn't get "written to" in the sense I was referring above when talking about PLC order of operations.

- First rung is evaluated, zero is stored in MI 1

- Second rung is evaluated, the value in MI 1 (currently zero) is compared to zero. It is true, therefore MI 1 is incremented. It is now 1.

- Third rung is evaluated, the value in MI 1  (currently 1) is compared to 1. It is true, therefore MI 1 is incremented. It is now 2.

The ladder is now complete and the outside world can now see that the value of MI 1 is 2.

Then we return to the first rung and start all over again with the same result.

Thank you very much. I think I understand it!

kind regards

Sven

[Isakovic]

On 8/14/2018 at 2:48 PM, acisre said:

No when rung 6 is executed, this rung also resets the timer.

True. I wasn't paying attention.

 

11 hours ago, acisre said:

I do have another question though: if I would leave out the timers in my program, I wonder what happens.

I can confirm that Modbus functions can be called one after another without delay (with "Modbus in progress" bit as condition) and it works without problems. As soon as one function is called "Modbus in progress" bit is set in the next rung blocking second function from being called before first one is finished.

Maybe if you called subroutine with CAN write functions after each of those rungs in the picture you first posted, it could work without timers. Although, I don't know if it would make any difference.

[kratmel]

16 hours ago, Isakovic said:

Maybe if you called subroutine with CAN write functions after each of those rungs in the picture you first posted, it could work without timers. Although, I don't know if it would make any difference.

My experiment with SDO via CAN  on V700  show that some times SDO is "lost" when i use only  "SDO in progress" NC contact.

Maybe it is due drive side behavior.

Then i use posted  ladder for transmit SDO. As i see PDO via CAN work faster on drive side and not need spetial sequance.  

[acisre]

9 hours ago, kratmel said:

My experiment with SDO via CAN  on V700  show that some times SDO is "lost" when i use only  "SDO in progress" NC contact.

Maybe it is due drive side behavior.

Then i use posted  ladder for transmit SDO. As i see PDO via CAN work faster on drive side and not need spetial sequance.  

Hi Kratmel,

The code that you posted, do you call it as a subroutine every time you need it?

small update:
I have rewritten some of the code with a "CANopen SDO Download STR" block in every rung, and this does seem to work without problems (and the machine is quicker to). But the code becomes messy kind of quickly, so I will probably try to make it into a subroutine

Sven

[kratmel]

I try to use this code in "main" but in result it go as "subroutine" that is called once in main program.

For parameter window where machine definatly stopped for setup i use  separate large SDO subroutine.