1ms bit shift for tracking

[LWright]

robertmee: Good question. There is about 0.8mm between increments and 1.1ms. If I expand that to 2 ms then the range per pulse would increase to 1.6mm. This might work. The only other issue was that when we previously checked on it, the time delay for the I/O increased as we added expansion modules and we needed 3 or 4 modules. You've given me some things to consider. Thanks,

 

[LWright]

Thanks drbitboy and OkiePC: It will take me a minute to get my head wrapped around this functionality. I can't even say if this will help or not.
You can see a couple of small older videos of the process at LinearGS(dot)com

 

[drbitboy]

btw, another advantage to the variable index suggested by OkiePC and me is that you don't care if the PLC misses any extra counts of the HSC between scans: simply increment END_INDEX by 2 or or whatever the inter-scan count increment is, instead of by 1.

to be fair, that may leave some blanks where e.g. camera inspection discrete bits with values of 1 are not written, but a pulse stretcher on the input should take care of that. The code should probably be writing multiple values of 1 to the array around the inspection station anyway; that is the kind of thing that will be tweaked empirically anyway to account for various stochastic delays.

 

[drbitboy]

 

[LWright]

That sums it up!!

 

[Peter Nachtwey]

I agree with the video. The PLC will be overwhelmed.
I have written a couple of real time operating systems or kernels to be more exact.
I used linked lists one a microprocessor. This is how RTOS keep track of delays. My RTOS would use either the timer/clock or encoder counts for delays.

 

[cleeton]

ControlLogix and CompactLogix would be limited in some respects.

CompactLogix supports only Instruction Event Interrupts.

ControlLogix supports Motion, Consumed and Data Change on an Input.

You can set up Periodic tasks to run at .1ms if you want, but you have to be careful with task overrun. In essence, whatever logic you execute in the Periodic task must have a shorter scan time than the periodic value. So if you set a .1ms periodic, the execution of the logic in that task must be less that .1ms worst case.

However with all that said, I don't know how you get around the RPI limitation of the CLX/CPLX backplane. Even the 1756-HSC card has a minimum 2ms RPI. Meaning the controller only polls the HSC card for data every 2ms.

Some Compactlogix support limited Input interrupt events. (The 1769-L1 series, and the 5069-IB16F). But like CLX need a minimum of 2ms.

 

[LWright]

I guess what I do must be unique for Rockwell to discontinue this functionality. The videos on the website are showing parts being tracked by the ML1400. I have considered moving to an FPGA or microcontroller if that is possible.
Peter Nachtwey: I like the RTOS approach.
Thanks

 

[Peter Nachtwey]

I guess what I do must be unique for Rockwell to discontinue this functionality. The videos on the website are showing parts being tracked by the ML1400. I have considered moving to an FPGA or microcontroller if that is possible.
Peter Nachtwey: I like the RTOS approach.
Thanks

Lookup FreeRTOS. Writing one is tricky, so it is better to use one that is already written. The RTOS will put each future event in a linked list. I used doubly link lists. This get messy/tricky. All the future events that depend on encoder counts get threaded on to this list in order of number of encoder counts to go. The RTOS only looks at the entry that has the lowest number of encoder counts. There are 3 ways to handle this but because the RTOS is only looking at the event with the lowest number of counts till the next event, it is very efficient. Motion controllers have been running at 1ms updates for years. Now there are low power 32 bit ARM chips that have more than enough power.

A while back, forum member tinine was bragging about his propeller chip. That would probably work too.

If you only need one RTOS then
https://www.lynx.com/products/lynxo... - Tech&utm_term=rtos system&utm_content=RTOS
may be better as it is a commercial package that isn't too expensive and I know it has been around for a while.

 

[drbitboy]

Hi everyone! I'll go a little more in-depth. ...I use an STI set to 1 ms to handle all of the tracking logic. ... I can have one or more bit shifts to track presence, pass, fail, etc.

Does that mean that, in a single 1ms STI event, you sometimes shift the array of bits by more than one bit position?

 

[JeremyM]

Hi All. I have a very specific question about tracking using an encoder and bitshift register. We would like to use a Compact or Control Logix PLC but when we tried a few years ago (>5) I found that we couldn't get it to work as well as the ML1400. It was limited by the I/O scan time. On the ML1400 we track multiple objects (>300) at up to 1000 increments a second with 20480 bits (5 x 4096). We also have numerous devices attached where we check the time and distance between events. I would like to keep the 1ms cycle time and if possible shift more bits. Is this something anyone else has done? I don't know how to overcome the I/O limitation and mostly just want to know if it is possible but pointers on how to do it in a Compact or Control Logix are appreciated. Thanks, Larry

To inject some unnecessary facts into this conversation, you can tie a Compact/ControlLogix HSC module's inputs to an EVENT trigger in Logix that will cause the processor to go straight to your EVENT task handling code, not pass GO, not collect $200, and I also won't collect $200.

 

[robertmee]

To inject some unnecessary facts into this conversation, you can tie a Compact/ControlLogix HSC module's inputs to an EVENT trigger in Logix that will cause the processor to go straight to your EVENT task handling code, not pass GO, not collect $200, and I also won't collect $200.

The Event trigger still relies on the Tag value from the module which is subject to the RPI Update. The Tag is still lagging the actual input by 2ms or more. Also, if looking at the encoder channel of the HSC, the pulse rate would be changing faster than the execution time of the event task. It would end up calling multiple instances of the event before the first one processed, creating task overruns and minor faults. If you have an example of how to do this to avoid the above, would love to learn.

 

[drbitboy]

The Event trigger still relies on the Tag value from the module which is subject to the RPI Update. The Tag is still lagging the actual input by 2ms or more. Also, if looking at the encoder channel of the HSC, the pulse rate would be changing faster than the execution time of the event task. It would end up calling multiple instances of the event before the first one processed, creating task overruns and minor faults. If you have an example of how to do this to avoid the above, would love to learn.

I think @JeremyM is suggesting the PLC should detect the interrupt at the rising edge and to do a minimal amount of processing in the triggered interrupt task routine e.g. increment the base index in the circular array, handle wraparound, and then get out i.e. return.

In the continuous task, the first step would be to buffer (CPS*) the current base index, so those interrupts won't muck anything up.

* Synchronous COPy i.e. "While the CPS instruction copies the data, no I/O updates can change the data;" cf. Example 4 description here.

But I agree that, overall, the 2ms RPI may define the time resolution limits/capability of any approach. I noticed that, with the MicroLogix 1400, @LWright said the code was using the "immediate input" of the HSC count; I assumed that "immediate" meant bypassing any RPI limitations.

This is similar to coding using threads in Linux/Unix(tm):

• you have to know how the underlying hardware and operating system works,
• and even so, it gets veru fiddly, and very complicated, very quickly.

 

[LWright]

drbitboy: It is possible because of the immediate I/O to read I/O perform a bit shift, logic, and write I/O but the truth is that with the ML1400 taking 1/2 to 3/4 of a millisecond for the tracking logic, it becomes possible to prevent the PLC from finishing a normal program scan and it can fault. I do capture moves faster than 1 ms. Because all I have in the interrupt is an add function. I then in the 1 ms STI process them one at a time. This means that I end up with enough processing time left over for the PLC to finish its normal scan.

 

[drbitboy]

So the 1ms STI routine calculates the difference in the HSC count from the previous STI event, and adds that difference to some accumulator. Then in the continuous task the code will "burn down" the value in the accumulator to zero, e.g. one shift = decrement accumulator by 1. Is that roughly correct?