Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Tam1117 on August 07, 2017, 12:11:54 PM
-
I am working on a project that needs 20 event interrupts triggered by inputs to catch an encoder pulse count for each event.
I like the BRX but it has only 4 input event triggers.
Thanks.
-
I am working on a project that needs 20 event interrupts triggered by inputs to catch an encoder pulse count for each event.
I like the BRX but it has only 4 input event triggers.
Thanks.
Can you describe exactly what you are trying to do? Maybe there is another way to solve the same problem.
-
It is a automatic register control system. The system is for 10 stations, each station has 2 optical sensors to monitor the relative position between two cycling moving objects. The two sensors connected to the controller act like a stopwatch, one for START and one for STOP, except that the controller does not measure time but relative distances between moving objects with high precision. This same measurement is taken at every rotation of the cylinder, so the controller monitors in real-time the exact relative position between the target on the cylinder and the register mark on the web. There is an encoder connected to the controller, the controller needs to catch the pulse-count every time the two sensors are triggered, subtraction of those two pulse-counts is the relative distance.
Thanks for the question.
-
How fast do the events come in, how many pulses per second is the encoder generating, and what is your tolerance on the relative calculation?
-
Hi BobO,
The speed is 175'/min = 35"/s, within a station the events will come approximately 12" apart (.3428 second )but with 10 stations it is hard to tell!
The tolerance will be < or = .03125". The encoder will be 2500 pulse/ rev with 2 channels = 10,000 count/rev at 2.9 rev/s, so the encoder frequency will be 29,000 Hz (29KHz).
-
The speed is 175'/min = 35"/s, within a station the events will come approximately 12" apart (.3428 second )but with 10 stations it is hard to tell!
The tolerance will be < or = .03125". The encoder will be 2500 pulse/ rev with 2 channels = 10,000 count/rev at 2.9 rev/s, so the encoder frequency will be 29,000 Hz (29KHz).
I'm pretty sure he's talking about speed for the two related marks within one station. Also, one count is leading + trailing edge, so it would be correct to say that you have two, 7.25KHz pulse trains for one quadrature encoder. (Though yes, you obviously have to check at more than double that rate, but that's already assumed with a given frequency)
-
Hi BobO,
The speed is 175'/min = 35"/s, within a station the events will come approximately 12" apart (.3428 second )but with 10 stations it is hard to tell!
The tolerance will be < or = .03125". The encoder will be 2500 pulse/ rev with 2 channels = 10,000 count/rev at 2.9 rev/s, so the encoder frequency will be 29,000 Hz (29KHz).
At 29KHz, your 12" events are 9941 pulses wide, so 1 pulse is about 0.0012". The time tolerance is then (0.03125/0.0012)/29000, or 893us. That's fairly relaxed.
I was first thinking you might be able to do multiple triggers on a single event, but I think that will miss triggers.
With a tolerance of 893 us, you might be able to use a timed interrupt. I hacked up some code to fire the interrupt every 800us, and then test for the rising edge of X0-X9, and stored that value in D0-D9, and the falling edge of X0-X9 and stored the difference between D0-D9 and .Acc and stored in D10-D19. Interrupt latency plus execution is very stable at about 35us. The entire routine is the 10 rising edge rungs, 10 falling edge rungs, and the last rung that stores the previous input state for edge compares.
Note that you cannot use edge based instructions in the ISR, which is why I create my own edge. I'm also using the MATH box for basic moves because it is accelerated for integers, and I can't remember if the MOVE is. The key to making this work is the use of accelerated instructions for everything...it's fast.
-
I think you're going to actually need to look at four inputs per station if I'm following him correctly. Drum target sensor, web mark sensor, and A and B channels of the encoder (and both rising and falling edges for the encoder channels), so 6 edge detections per station (plus the quadrature counting logic).
You have to count continuously and note the count when you get to the first mark sensor, then note the count when you get to the second sensor, and subtract to get the distance. You probably also have to keep track of the sign of the difference based on whether you saw the drum or web mark first.
-
Hi BobO,
The speed is 175'/min = 35"/s, within a station the events will come approximately 12" apart (.3428 second )but with 10 stations it is hard to tell!
The tolerance will be < or = .03125". The encoder will be 2500 pulse/ rev with 2 channels = 10,000 count/rev at 2.9 rev/s, so the encoder frequency will be 29,000 Hz (29KHz).
At 29KHz, your 12" events are 9941 pulses wide, so 1 pulse is about 0.0012". The time tolerance is then (0.03125/0.0012)/29000, or 893us. That's fairly relaxed.
I was first thinking you might be able to do multiple triggers on a single event, but I think that will miss triggers.
With a tolerance of 893 us, you might be able to use a timed interrupt. I hacked up some code to fire the interrupt every 800us, and then test for the rising edge of X0-X9, and stored that value in D0-D9, and the falling edge of X0-X9 and stored the difference between D0-D9 and .Acc and stored in D10-D19. Interrupt latency plus execution is very stable at about 35us. The entire routine is the 10 rising edge rungs, 10 falling edge rungs, and the last rung that stores the previous input state for edge compares.
Note that you cannot use edge based instructions in the ISR, which is why I create my own edge. I'm also using the MATH box for basic moves because it is accelerated for integers, and I can't remember if the MOVE is. The key to making this work is the use of accelerated instructions for everything...it's fast.
I'm not following. Are you trying to do the quad counting in the ISR or are X0-X9 supposed to be the drum and web mark sensors (in which case you need 20 sensors, but probably not both leading and trailing edges each)? If you're not doing the counting in the ISR, then I think he needs one encoder per station for a total of 10, so can you still do that in built-in HSC's?
-
I think you're going to actually need to look at four inputs per station if I'm following him correctly. Drum target sensor, web mark sensor, and A and B channels of the encoder (and both rising and falling edges for the encoder channels), so 6 edge detections per station (plus the quadrature counting logic).
You have to count continuously and note the count when you get to the first mark sensor, then note the count when you get to the second sensor, and subtract to get the distance. You probably also have to keep track of the sign of the difference based on whether you saw the drum or web mark first.
Encoder is hardware. Just hook it up.
As for the other, doesn't matter if he uses every high speed input on a -36, as long as he does accelerated instructions it's going to stay within a reasonable execution time. I was just doing a simple proof of concept on the -18 sitting on my desk. In the end, avilable fast inputs will be the limitation, not the PLC's ability to do the work.
-
I'm not following. Are you trying to do the quad counting in the ISR or are X0-X9 supposed to be the drum and web mark sensors (in which case you need 20 sensors, but probably not both leading and trailing edges each)? If you're not doing the counting in the ISR, then I think he needs one encoder per station for a total of 10, so can you still do that in built-in HSC's?
He said there was a single encoder for everything.
I'm just using a timed interrupt to mark the current encoder count on the 10 inputs. Point was just to prove that the problem could be moved into the time domain, generating events from the edge detection.
-
Hmm, I thought he'd said one encoder per station, maybe that was in the other thread.
-
Thanks for answers and questions.
Now I have another question; can BRX handle quad counting like H2-CTRIO2 ?
-
Hmm, I thought he'd said one encoder per station, maybe that was in the other thread.
I thought he said 1 encoder for all stations, not each. Regardless, I think he doesn't have enough fast inputs in a single PLC, and for any of this to work, the encoder input and sensor inputs are going to need to be in the same unit.
When we release the HSIO (hopefully early next year), that will add more fast inputs, but the backplane won't be as fast as the onboard I/O, so the latency will need to be studied harder.
-
Now I have another question; can BRX handle quad counting like H2-CTRIO2 ?
Yes. Three quad channels onboard.
-
Regardless, I think he doesn't have enough fast inputs in a single PLC, and for any of this to work, the encoder input and sensor inputs are going to need to be in the same unit.
You are right, the plc doesn't have enough inputs, I have to use couple of them. Thank you for your time.