Conveyor Indexing Optimization

[JSB 0]

Hi All, New to the site, and I'm looking for some input on an application I'm developing. The application consists of an oven with a chain conveyor which has position read via an encoder, and has speed determined by a vfd. The condensed sequence is as follows: Operator initiates index sequence via HMI Doors Open Conveyor jogs back (approx 5") Table drops to load part on chain Conveyor jogs forward (approx 25") Doors Close (if clear) I'm having an issue with the repeatability of the index moves. At times I can index several parts and have everything spaced where I need them to be. Other times during the the first reverse jog movement the plc seems to lag in counting the encoder pulses while the conveyor is indexing, which leads to it jogging back to far and throwing part spacing off for the whole sequence. The conveyor is moving approx 2" per sec (35hz via vfd through a 10:1 reduction I believe). I do not have the specs of the encoder with me, but can post them later. I'm using a L32E cpu and the encoder feeds into an IQ16F module that is dedicated to it only. The RPI for the IQ16 is set for 1ms. I moved the encoder logic from a subroutine in "main program" to its own program and moved its tags into controller tags in hopes of speeding it up. I'm still having the count delay issue assuming something is flawed with my logic to move the pulse index, or am I missing something silly in the configuration of the module or cpu? This is my first application ever using an encoder, I'm sure there is better technique to do what I'm trying to do. I am not an EE just a tech with enough knowledge to stumble through this. Please see the portion of code attached. Any assistance would be greatly appreciated. sample_code.ACD

[travish 0]

If I understand you are basically running the conveyor at some speed thru the VFD and then stopping at some preset encoder count? Is that correct? Are you doing some kind of controlled stop or is the drive just coasting to a stop? Might not have anything to do with accuracy but why not use a high speed cntr instead of creating your own encoder logic? Travis Edited 1 Nov 2012 by travish

[Ken Roach 194]

At first look, it seems like you're asking a general-purpose PLC and input module, plus a general-purpose VFD, to do the job of a motion controller. If the Input module can handle 1 millisecond updates, that limits the incoming pulse train to 500 Hz because it needs to see both a 1 and a 0 to count a "pulse". If you need to determine direction (which your code appears to do), that limits you to 250 Hz. If we make some general assumptions of a 1800 RPM standard motor, and using the 35 Hz motor frequency you described, that's 1050 RPM = 17.5 revolutions / second. If you're limited to 500 Hz input (let's assume we know direction because we're commanding the VFD), that means the encoder can't be more than 28 pulses/rev. This of course assumes that the encoder is on the motor shaft, rather than on the output shaft. If the encoder is on the output shaft (10:1 reduction) you could keep up with 280 pulses/rev. Post more details. It sounds to me like you simply hav a pulse train that's too fast for the controller to handle. I don't see any analog output modules or devices on Ethernet; is the VFD just getting its speed reference from a potentiometer or dial ?

[BobLfoot 301]

One quick random thought that might divide and conquer this problem. Instead of using the encoder, try a fixed time say 1 second backwards and 5 seconds forwards with some cardboard dummy parts in a cold oven and see if your spacing is repeatable. If the spacing varies on time then you're looking at VFD related cost to stop and scan time issues on your cpu. If the time based test case is repeatable then you're lookng like has been said at an encoder moving faster than the system can handle.

[JSB 0]

[JSB 0]

The drive speed is set via the front panel pot (currently 35hz) The encoder is a 500 ppr resolution. I was way off on the gear reduction used it is 150:1 I am not sure which shaft the encoder is located on. I will look into it

[dmargineau 6]

Ken's post admirably sums up the issues with your application's development approach. Since it is the first encoder application you are undertaking this might sound strange, however, you should always start by first evaluating your system's capabilities; timing might sound as a trivial issue when talking about extremely fast and capable CLX class CPUs, however, your feedback device (encoder) is also extremely fast and accurately acting. A CLX class digital input was developed in order to capture the change of state of field input devices such as push buttons, limit switches, proximity swtiches, etc. On the other hand, since the early ages of PLC controlled systems, the manufacturers have been producing hardware specifically dedicated to capturing the data arriving from fast counting position feedback hardware such an encoder; basically, the HSC (high speed conter) module is processing the data prior to the system's CPU and they are doing this at nano/microsecond level update for the latest generations. A very slow application might be able to accurately use an encoder connected to a digital input module, however, 99% of the encoder applications I have encountered require the use of a High Speed Counter module; I highly recommend exploring the usage of one of these devices (1769-HSC in your case) within your system. Edited 1 Nov 2012 by dmargineau

[OkiePC 14]

I would lean toward giving the PLC control of the VFD speed reference, thereby closing the position loop in the PLC. Then you can ramp into a position within a count or two of exact every time. This is not really complicated in the PLC, you simply subtract to get a position error, then use that error to scale the speed command, limit it to a max value, and a minimum (to prevent stalling) value. What you will likely find is that this ramping effect costs you a little bit of cycle time, but you will also find that the top speed may be increased without sacrificing accuracy, so you can more than make up for this lost cycle time and end up with a faster machine.

[Guest]

WARNING! this could be a "chase of the wild goose" - but - for what it's worth, here's something else to consider ... DISCLAIMER: the following ideas might have NOTHING to do with your problem ... but based on how you're using the PLC logic to "analyze" the signals from your encoder, I recommend that you at least take a look at the following "demo" code ... note that the input is being fed by an ON/OFF pulse train with a 10 millisecond period (from a separate PLC) ... the RPI of the ControlLogix input module is set for 1.0 millisecond ... this rung says: if the input bit/box contains a ONE - and - if the SAME input bit/box contains a ZERO - then increment the accumulated value of Inconceivable ... common sense tells us that the counter should never advance - because there is no way for the same bit/box to contain both a ONE and a ZERO at the same time ... but this is a case where "common sense" doesn't seem to work ... actually the counter does indeed advance ... it's random – and it's intermittent – but it DOES advance from time-to-time ... the number 62 that you see in the test represents how many times the "inconceivable" happened while I was typing up this description ... the "trick" depends on the ASYNCHRONOUS nature of the processor's scan cycle ... specifically, the ONE/ZERO status of the input bit/box can be updated (with the present ON/OFF field conditions) PARTWAY through the rung execution – including RIGHT BETWEEN the executions of the rung instructions ... so ... actually the bit/box NEVER really does contain a ONE and a ZERO at the SAME time ... but ... the status of the bit/box occasionally DOES suddenly change from a ONE to a ZERO during the brief sliver of execution time between the two conditional instructions ... in some cases – particularly where FAST changing inputs are involved – this effect can cause unforeseen issues ... some PLC practitioners having a great amount of experience with (older) SYNCHRONOUS scan sequences will sometimes misdiagnose problems related to this newer ASYNCHRONOUS way of handling the PLC's input and output signals ... my point in raising this topic for discussion is that your logic seems to be relying upon the ON and OFF signals from your encoder - which MIGHT be changing status PARTWAY though your rungs ... I haven't had time to dig through all of your logic to see how this might affect your system's operation – but I suggest that you just keep this ASYNCHRONOUS scan issue in mind if all else fails to diagnose your problem ... going forward: you might consider setting up a few extra "test rungs" along the lines of this one – just to see if these concepts MIGHT be a problem ... good luck with your project ... Edited 1 Nov 2012 by Ron Beaufort