HSCE2 Counter Card for SLC

[IamNotaCat 0]

Hello,

Hoping for a little insight on this Counter Card. I am new to a small company, they've have many 'issues' ongoing for long periods of time that never got solved. One comes from an HSCE2 Card. What they are doing is taking the Rate value off a HSCE2 counter card, and converting it into FPM. They actually had the scale improper, but I fixed that. (They were always showing ~11% faster run rate than actual because improper values in Scale with parameters function). Now that I have fixed that what they did is took that Rate value converted into Feet per minute, then scaled that from 1-32,767 and set it out as a differential analog output, going to the analog input of another PLC. In the other plc, once they re-construct it back to a FPM calculation it gets strange again.

They take 60 seconds and divide it by the FPM. This makes sense I believe, because say 100 Feet per minute. 60 seconds / 100 feet per minute = 0.6 seconds per foot ran. They then take this 0.6 seconds value that is obviously a constantly updated variable depending on how fast they are running and moving it to a Preset value of a timer. Now they use this timer to generate a 'Pulse' for every foot ran.

After fixing the Rate value to get the proper FPM, I replicated this conversion to the foot pulse they made, which of course ends up with a x100 because the timer is in Deci-seconds in the SLC 5/04, and something doesn't add up. If I put a 60 second timer after 60 seconds move the count into a holding register to view it, it is always way less than the FPM from the rate value, which has been verified to be correctly monitoring the speed now. I mean, say the timer preset value is 0.7 seconds. 60 seconds / .7 seconds = ~85-86. So after 60 seconds, it wont have counted the counter to 85 or 86, it will be like 80. Is this a scan time issue? I mean logically speaking if I put a .7 value in a timer, and have its own XIO .DN instruction resetting it every time it finishes, as fast as the scan can reset it, and then immediately under that the XIC .DN bit counts up a counter by 1, THEORETICALLY, after 60 seconds I should have my full count, not drastically under. 

Is this why the HSCE2 card gives a rate value AND a counter, because using one to mathematically construct the other in the processor is an inaccurate process? The counter is hooked up as well on 1024 PPR pulse tach, so on the front end the PLC it goes to has an accurate count. But then they send rate value over analog signal to other PLC , rate value now seems accurate after fixed scales, but the construction of a 'Foot counter' from the rate value is not working properly. Could I send the "count value" over an analog channel as well? Scale the 0-1024 PPR to 1-32,767, then on input side take the 0-10000 mv and scale back to 0-1024? 

Sorry for the text book!

[panic mode 246]

rate is secondary value (it is a first derivative of position) and inherently inaccurate due to low sampling rate and further processing that all have own rate and latencies (signal conversion to analog, transmission, conversion back from analog to digital, integration using goofy logic with timers). 

why not use HSCE to generate pulse for each foot of travel? why not do everything in one PLC?
if transmitting values to another PLC, why not use digital signal instead of analog?

 

[IamNotaCat 0]

1 hour ago, panic mode said:

rate is secondary value (it is a first derivative of position) and inherently inaccurate due to low sampling rate and further processing that all have own rate and latencies (signal conversion to analog, transmission, conversion back from analog to digital, integration using goofy logic with timers). 

why not use HSCE to generate pulse for each foot of travel? why not do everything in one PLC?
if transmitting values to another PLC, why not use digital signal instead of analog?

 

They are using HSCE to generate the foot pulses in the first PLC, then they sent an analog signal over as the rate value to the other PLC and attempted to re-construct a foot pulse off the rate value. It didn't help the rate value sent wasn't even properly scaled. I am going to upgrade the SLC 5/04 to a CLX that is getting the analog signal of the rate value and wanted to attempt to get this issue fixed with the controls change. As of right now neither PLC has any communications between the two, and whoever set it up ~15 years ago chose to use analog signals to send the information over. I can of course change whatever I want in the PLC they are letting me upgrade, but as of right now, I cannot touch the other one. They are both SLC 5/04 I believe. As I am unfamiliar with the HSCE2, I only did some reading on it upon encountering this issue, I was curious why if they wanted a foot pulse they sent over an analog rate value as well instead of a digital output of a foot pulse that an input could read and increment an internal counter. But they also wanted a FPM value to scale back to an analog output over Flex IO and send to a display meter on a panel. I plan to eliminate all the display meters and just put the values on an HMI there now, so I guess that portion is irrelevant, except they want both a FPM value and a foot pulse counter. The foot pulse is being used to track faults down the line. I.e. if NDT tester evaluates an error, and the offload of faulted product is 64 feet down, once 64 pulses have occurred they know the faulted item is at the spot to remove it. Being the ineffectiveness of the code, they've always resorted to faulting everything +/- 10 feet from the 'faulted product'. It has been good enough to get ball park range and then do so that way. 

 

I assume with a PLC upgrade they expect things to work better, so I don't want to upgrade the PLC and leave old issues present. As far as my question of if I could send the counter value over as analog, that makes far less sense than using a digital wire, I just already had analog wiring pulled so I was curious. 

 

I think after reading what you said and typing my response... my best course of action is to create a digital output from the first PLC when a pulse occurs and run that to an input wire in other PLC. Max line speed is governed at like 120 FPM, so the standard digital I/O should be able to keep up with that just fine and not lose counts I imagine. 

[pcmccartney1 141]

Well if you upgrade both SLCs to CLX then you could message or do produce/consume via ethernet and eliminate the need to the AO to AI and logic to recreate the pulse.