Jump to content

Recommended Posts

MI2 & MI3 should be able to range from 1 to 240, with MI2 being less than MI3.

The question was, what do YOU have them set to?

Anyhow ........

MI0 is your encoder count. All MI have a range of -32768 to +32767.

That means the largest value you can measure in MI0 is 32767.

In your code you multiply that by 0.00293

So, 0.00293 * 32767 = 96.00731

Once it passes 32767 it will jump to -32768, so you immediately jump to negative numbers. So it is NOT counting back down. It is infact counting back up from -96.

You need to set the encoder rollover point and then either have it automatically reset, or use the marker pulse on the encoder to reset it.

You then need to keep track of the rollover times separately.

For example, if you have a 1000 line encoder you will get 4000 counts/rev. Set it to roll over at 4000. Everytime it goes from 4000 to 0, increment an MI or ML integer. Your total distance will now be that integer + the fraction that remains on the encoder.

Also, a word of caution. You have your screen set up for 9 decimal places. The floating point arithmetic in the PLC is not anywhere near that precise.

Link to post
Share on other sites

Damian - good description of the mystery maximum value.  We still need to know a few things to be really helpful:

1.  What is the encoder counts/rev?
2.  What is a typical pre-scale value?
3.  What is the implied precision of MI 2 and MI 3; you mention 1 to 240, but are these indeed supposed to represent integer values?

If you don't use a reload type high speed input then you can use an ML as the accumulator.  This application looks like a feed-to-length program and you probably won't lose a lot of precision if you reset the counter in ladder logic.  You're not using the reload event MB 18 anywhere, and you enable the reload MB 19 with a real input.  This tells me that you don't need the micro-second timing the reload function provides, and it's really not the right way to use this function.  The "Enable" input on a reload high speed input does just that - if the counter is > the preset then it resets.  I think you're treating it as a straight reset input, which it isn't.

I'm going to go on the assumption that 1 to 240 represents inches with no decimal place.  I'm also assuming that MI 2 is a slowdown preset and MI 3 is a cut preset.  This is a typical method of feeding.

Since the reload type high speed input really isn't needed, I've moved the input to a regular high speed input and used an ML.  I've modified the shear logic to reset it when I7 comes on.

Also - high speed inputs do not remember their value when power is cycled- they always go back to zero.  I've got a standard bit of logic I put in to handle that.

Joe T.

J3920 Trim Line HMI Touchscreen - no home position JT.vlp

Link to post
Share on other sites

Hi Damian and other participants to this discussion,

First - I want ot thank Damian and Joe for their very useful notes and advices.

About "MI" limitation in function HSC (Reload) - in some Vision models this is hardware limitation, which cannot be ommited.

In some newer models, like V130/350 "TR" ones - you alrady can select both for the counter and the target MI, ML or DW.

Link to post
Share on other sites
  • 7 years later...

Hi All,

I was wondering could I get some advice.

I have a V130-33-TR20 plc and am looking to program a simple enough application. 

1 motor which moves a backstop on a guillotine, 0-750 mm variable distance.

I have a new 1024 ppr encoder on the machine.  I have wired a and a- to input 0 and 1.

From 0 -750 mm the plc counts roughly 155000 pulses. there is no brake on the motor so when it reaches the out limit switch there is a variation on when it stops. plus or minus 300 pulses

I thought it would be simple math. Therefore 155000 / 750 mm = 206.6 pulses per mm.

Therefore if I want the backstop to go to 200mm. the code would simply wait for (200*206 =  41334 pulses) and then that is the target. The issue I am having is the counts from the encoder must be drifting as when you give it the command to go to a distance it could be off by 10mm, or 5mm, however does not seem to be any consistency  which i would have thought an encoder would bring.

I have attached my code just wondering am I doing something wrong. Also to note I am new to unitronics.

Below is the link to my encoder



Any help or advice would be appreciated



Link to post
Share on other sites

What kind of motor are you using?

I don't think it's an encoder issue. From your explanation it seems the inertia is causing inconsistency in positioning. It's hard to drive the system precisely with start/stop motion with relatively fast motor. If steppers and servos are out of question maybe you can try with VFD. To have a significantly slower speed when you approach desired position. Or add a gearbox, if there is space and speed reduction isn't much of an issue for machine performance.

Since you mentioned motor with brakes. I had one project where I had control done just as you did here but with braking motor. Precision was 1-2mm (within tolerance for the project), even when carrying heavy load. Brakes wear off fast though.

Link to post
Share on other sites

Thanks for your reply.

It is a MEZ 3 phase motor, which has a running speed of 705 rpm. I have put a vsd on it, which I have set to 40 hz, but as a test I could half it to 20 hz and see if I am getting more consistency.


Link to post
Share on other sites

Thanks for your reply.

It is a MEZ 3 phase motor, which has a running speed of 705 rpm. I have put a vsd on it, which I have set to 40 hz, but as a test I could half it to 20 hz and see if I am getting more consistency.

Also just to note, if I tell the machine to go to 200mm like my original example, which should be 41334 pulses. when it stops, the pulse count is in fact 41334, correct me if I am wrong but I was thinking if it was due to the motor not stopping bang on in this position, then the encoder count should not be equal to the desired count? I would imagine the encoder count to be out due to the drift on the machine.


Link to post
Share on other sites

You're not somehow turning off the encoder reads when you stop the motor?  So that the "inertia position" isn't being registered properly.  I haven't looked at your program.....yet.

cheers, Aus

Link to post
Share on other sites

OK.  I had a quick look at your program and the thing that immediately stands out to me is that you have far too much going on in each rung.  Often you have set and reset in the same one.  A favourite saying here is that "Unitronics doesn't charge for the number of rungs in use".

So go through it all again, and split each and every "action" into another rung.  Quite often crammed rungs do not behave as one would expect, as the plc interprets them differently to the user.  Once you have cleaned it up, load it again but before doing any running also do an Initialise and Reset.

That said, have you ensured that the encoder count is not varying when the motor is completely stopped?

cheers, Aus

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...