PLC Pie Guy said:
...Now for the solution you proposed. I don't understand why... but it worked! I first tried setting Ctrl0RisingEdgeZ to 1 with the Ctr0En set to 0, it didn't work, then I tried while Ctr0En set to 1 and it took off.
Why???...
...I'm realizing now that I have to keep the Local:x:O.Ctr0ResetRisingEdgeZ set to 1 in order to get the rate to keep moving...
Glad to here it has kick started. Sometimes that is all it needs.
As I'm sure you are aware, the Z output is an index signal that is pulsed once per revolution. Does your encoder have a Z output (it appears to have), and if so, does your application require this signal?
You have "Preset on Rising Z" enabled and you have set a "Preset" of "1". This means that when an index signal is received i.e. a Rising Z signal, the Preset "1" should be written to "Ctr0CurrentCount". This means that the counter is configured to reset to "1" after every revolution. So the counter should only ever count up to how ever many pulses it usually receives for one revolution. Let's say "1024", then "1", then "1024", then "1", and so on. Your counter might be signalling the controller or a HSC output at a particular count like at "1" or "1024". Or, if using HSC outputs, there may be certain ranges configured on the module's "Output Configuration" tab?
When the Rising Edge Z signal is detected, and the Preset loaded to the counter, the input "Ctr0RisingEdgeZ" is also latched ON. However, you must programmatically reset or unlatch this Rising Edge Z signal. Otherwise "Ctr0RisingEdgeZ" will latch the first time and then remain latched ON. While latched, you cannot detect further Rising Edge Z signals and "Ctr0CurrentRate" will freeze at whatever value it was at when the Rising Edge Z signal was triggered. If only starting off for the first time, and the rate is at "0", then it's possible that the first Rising Edge Z pulse will be detected before the rate has been calculated and displayed. So it appears to be frozen at "0".
You have "Update Time" = "1000" ms which is a relatively long time (default = 10 ms), but it depends on the application. This time interval is used to calculate the rate of the pulses. The number of net counts, net change in "Ctr0CurrentCount", during that period is converted into the "Ctr0CurrentRate" value, providing an average pulse rate. You set the "Update Time" to allow enough time to calculate the slowest expected frequency. If that is around 1 second then OK. So, if the Rising Edge Z signal is detected before the 1 second update time elapses, the rate will not have been calculated and will remain at whatever value it was at, until you reset the Rising Edge Z signal.
To reset the latched condition you must transition the output "Ctr0ResetRisingEdgeZ" from "0" to "1" during the scanning of the high speed counter i.e. when "Ctr0.En" = "1" (as you have now realized). Once reset, the rate will begin calculating again, after 1 second update time has passed, and should display a value.
Remember, the reset only works by transitioning from "0" to "1" during scanning after the Rising Edge Z signal has been latched ON. By keeping the output "Ctr0ResetRisingEdgeZ" = "1" permanently, you are not allowing the Rising Edge Z signal to latch the input "Ctr0RisingEdgeZ" again and this is why it is not interfering with the "Ctr0CurrentRate" calculation.
Like I said, you have kick started it. But, again, do you need that Z index signal at all? You are not using it when you set the "Ctr0ResetRisingEdgeZ" output permanently to "1" on the machine application to get "Ctr0CurrentRate" active. If you don't need it then disable "Preset on Rising Z" in the module properties. That is how mine is configured and I have an active "Ctr0CurrentRate" value with the "Ctr0ResetRisingEdgeZ" output set to "0". If you do think you need it, or would prefer to leave the machine as it is, then you will need to add toggle logic to handle the resetting of "Ctr0ResetRisingEdgeZ", else that rate is going to remain static.
I've since found this but it doesn't really explain a whole lot. It just mentions the issue and fix...
33022 - 1769-HSC Current Rate Freezes when configured for Preset on Rising Z
Access Level: TechConnect
PLC Pie Guy said:
...On my test bench, It can be a 0 or a 1...
I would first check if there is any hard-coded logic for the HSC module in the machine controller, and not in the test controller, which may be influencing its configuration. I would also look at the two HSC modules (there are two in play here yes?) and check if they are the same hardware Series (A or B). I would also check the RPI for both modules for any difference. Also check the controller scan times for differences, and so on. Any little difference might tell us something.
Regards,
George