1ms bit shift for tracking

[robertmee]

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.

Correct, but he's talking about looking at the HSC "input". The only input on the HSC Card is the encoder pulse train. Even if the input change wasn't bound by RPI, I would presume the A/B channel frequency would exceed the possible event task scan time. Would obviously depend on the frequency of the encoder which I'm not sure was disclosed. That's only assuming the Event Interrupt operated outside the RPI. But it doesn't to my knowledge, so the point is moot.

By putting an event task on the HSC encoder input change, it would be equivalent to a 2ms periodic event, as at most the event would only detect a change at the RPI interval. You can set periodic events themselves less than 2ms, so the HSC event task wouldn't gain anything from a speed standpoint. Would gain utilization if the machine wasn't running and the HSC card not changing, but that's all I see as a benefit.

 

[LWright]

Thanks for your suggestions: It's good to know about the RPI limit. I believe I can replicate everything I do in the Micrologix except for the I/O limitation. In addition to the 2ms HSC interrupt, I'm also thinking about how the input and output delay can cause data to shift. Since several bit shifts need to synchronize the data to work.
Yes, the immediate input and immediate output instructions eliminate the need for I/O scan consideration because on the ML1400 this is direct I/O to the controller. The ML1400 also has expansion I/O but this is also limited by the cycle time of the I/O scan.
JeremyM: Thanks for the reading material. I found this bit on "https://rockwellautomation.custhelp.com/".
"The embedded I/O on the 1769-L16ER-BB1B, 1769-L18ER-BB1B, 1769-L18ERM-BB1B and 1769-L19ER-BB1B controllers are the only 5370 series CompactLogix controllers in which COS is supported."
I'm going to research what they mean by "embedded I/O". This sounds like it might be what I'm looking for.

 

[JeremyM]

This is what can be done in 5000. The IO module's RPI, not program scan time, is the only thing you'd have to worry about. Within your Event task, you could handle the response to a detection.

OP of course is using a 1400.

 

[robertmee]

This is what can be done in 5000. The IO module's RPI, not program scan time, is the only thing you'd have to worry about. Within your Event task, you could handle the response to a detection.

OP of course is using a 1400.

Right, but that's the problem is the RPI....Minimum is 2ms and the OP needed 1ms update on the data. Also, that Local address from the HSC is the encoder input....If the encoder is constantly pulsing at say 10KHz, that's going to be a problem. You'll likely have task overrun.

 

[LWright]

Hi Guys,
Since most of my work has been done on a ML1400, I'm surprised to find that it has better capability in this one way than the more expensive models. Even the Rockwell - Allen Bradly reps assumed they could do this. None have been able to help.
Maybe the terminology is throwing me but I'm hoping the "embedded I/O" is special where it might have the ability to have the "IIM" (Immediate) instruction on the I/O. There must be a reason why only the "embedded I/O" models have "in which (Change of State) is supported". Haven't had a chance to research it yet. If I could do what JeremyM suggested and use an input to fire an event that might work. I don't understand how that would work yet but I'm going to look into that and continue to consider the RTOS system.
Larry

 

[robertmee]

Hi Guys,
Since most of my work has been done on a ML1400, I'm surprised to find that it has better capability in this one way than the more expensive models. Even the Rockwell - Allen Bradly reps assumed they could do this. None have been able to help.
Maybe the terminology is throwing me but I'm hoping the "embedded I/O" is special where it might have the ability to have the "IIM" (Immediate) instruction on the I/O. There must be a reason why only the "embedded I/O" models have "in which (Change of State) is supported". Haven't had a chance to research it yet. If I could do what JeremyM suggested and use an input to fire an event that might work. I don't understand how that would work yet but I'm going to look into that and continue to consider the RTOS system.
Larry

The ML1400 doesn't suffer from having to have a universal backplane design capable of integrating a multitude of modules to a main processor. It's all embedded and a singular design in the case of the MicroLogix. The CLX L7 and L8's are enterprise solutions for large processes, motion control, multi device control, etc...It's like wondering why a formula 1 car isn't suited to a demolition derby. One is a far more expensive and capable car, but doesn't excel at a particular task.

 

[JeremyM]

Right, but that's the problem is the RPI....Minimum is 2ms and the OP needed 1ms update on the data. Also, that Local address from the HSC is the encoder input....If the encoder is constantly pulsing at say 10KHz, that's going to be a problem. You'll likely have task overrun.

The minimum available RPI for the 5069-HSC is 0.2 ms and the address struct contains the configured event output data, not a raw pulse.

 

[LWright]

I wish there was a "thumbs up" or a "thank you" button.

 

[JeremyM]

Hi Guys,
Since most of my work has been done on a ML1400, I'm surprised to find that it has better capability in this one way than the more expensive models. Even the Rockwell - Allen Bradly reps assumed they could do this. None have been able to help.
Maybe the terminology is throwing me but I'm hoping the "embedded I/O" is special where it might have the ability to have the "IIM" (Immediate) instruction on the I/O. There must be a reason why only the "embedded I/O" models have "in which (Change of State) is supported". Haven't had a chance to research it yet. If I could do what JeremyM suggested and use an input to fire an event that might work. I don't understand how that would work yet but I'm going to look into that and continue to consider the RTOS system.
Larry

The idea is that in the HSC module's properties, you would set it up for the lowest possible RPI, 0.2 ms.

Preferable to place the card as close to the processor as possible, so data doesn't have to take the path through the other IO cards' backplane ASICs.

Then if you head to page 32 in this manual, you'll see your other configuration options:
https://literature.rockwellautomation.com/idc/groups/literature/documents/um/5069-um006_-en-p.pdf

The card also embeds 4 outputs of its own that can be set up to behave based on preset conditions, removing any RPI concerns. So you could have a dedicated device apart from everything that waits for a single 24V signal and then takes some action.

 

[JeremyM]

Now, if you’re the adventurous type…

- You might acquire a Compact 5480
- Wire the HSC output to the controller’s UPS ‘B’ input
- Create a very frequent periodic task
- GSV(HardwareStatus, , UPSBuffering, YourTag)
- Trigger an event task with YourTag

… thereby removing RPI entirely.

 

[robertmee]

The minimum available RPI for the 5069-HSC is 0.2 ms and the address struct contains the configured event output data, not a raw pulse.

Ah sweet....then that certainly helps. The 1756-HSC is 2ms. Get creative and configure an output to some count (mentioned about 3 pages ago ), and then tie the output to the event, then certainly a plausible solution. Thanks for the heads up on the .2ms on the 5069 version.