BRX input processing time

[MarkTTU]

I have a pretty simple program that is calculating RPM for 32 different shafts. BRX CPU with two BX-16ND3 cards (published 2ms on/off transition time). Shafts aren't crazy fast, roughly 540 RPM with 4 pulses per second so expecting a pulse every 27ms. Scan time sits around 3800us until more than 16 shafts are running and then it starts to spike up to 7800us periodically. Still, I wouldn't think that would be an issue, but when those spikes happen the FREQTMR instructions start calculating much lower RPM than real world. Anyone have a thought on what is going on?

[BobO]

I have a pretty simple program that is calculating RPM for 32 different shafts. BRX CPU with two BX-16ND3 cards (published 2ms on/off transition time). Shafts aren't crazy fast, roughly 540 RPM with 4 pulses per second so expecting a pulse every 27ms. Scan time sits around 3800us until more than 16 shafts are running and then it starts to spike up to 7800us periodically. Still, I wouldn't think that would be an issue, but when those spikes happen the FREQTMR instructions start calculating much lower RPM than real world. Anyone have a thought on what is going on?

How wide is the pulse?

[MarkTTU]

I have a pretty simple program that is calculating RPM for 32 different shafts. BRX CPU with two BX-16ND3 cards (published 2ms on/off transition time). Shafts aren't crazy fast, roughly 540 RPM with 4 pulses per second so expecting a pulse every 27ms. Scan time sits around 3800us until more than 16 shafts are running and then it starts to spike up to 7800us periodically. Still, I wouldn't think that would be an issue, but when those spikes happen the FREQTMR instructions start calculating much lower RPM than real world. Anyone have a thought on what is going on?

How wide is the pulse?

About 4.3ms.

[BobO]

About 4.3ms.

With a base scan of 3.8ms, spiking to 7.8ms, you are gonna miss those often.

[MarkTTU]

About 4.3ms.

With a base scan of 3.8ms, spiking to 7.8ms, you are gonna miss those often.

Ya... working on a resolution for that now.

Have another question. In looking closer and using the max scan time memory to track (resetting it after things are running) I'm seeing some momentary spikes in scan time to crazy high numbers; like 119ms (119811us). Any thoughts?

[BobO]

Have another question. In looking closer and using the max scan time memory to track (resetting it after things are running) I'm seeing some momentary spikes in scan time to crazy high numbers; like 119ms (119811us). Any thoughts?

Loops? Something else in the logic? If not, there may be a hardware issue.

[MarkTTU]

Have another question. In looking closer and using the max scan time memory to track (resetting it after things are running) I'm seeing some momentary spikes in scan time to crazy high numbers; like 119ms (119811us). Any thoughts?

Loops? Something else in the logic? If not, there may be a hardware issue.

I have all of the programs that contain loops set to always yield so I wouldn't think any of those. Maybe a comm taking a really long time to complete? I changed my program to use the FREQCNT instruction instead of the FREQTMR instruction and now my scan rate is much more consistent around 3.2ms and the momentary spikes are down to 14-15ms.

Still missing some pulses, but that's an issue that needs to be resolved mechanically.

[MarkTTU]

Just wanted to report back on my resolution of this issue. I moved the RPM calculations into a dedicated PLC and all other code to a separate processor. The RPM calculations PLC enjoys a scan time of 1.1ms with a peak of 3.2ms and the other PLC has a san of 4-5ms with a peak of 15ms. No idea why having this code all together was creating those huge spikes, but seems to be working well as two separate bits of code with independent CPUs doing the work.

Bob, many thanks for getting me on the right track. Up until you asked how wide the pulse was I wasn't even looking at that and it wound up being the core issue I was having.

[BobO]

Glad it's working! Happy to help.