MPG axis jog velocity/acceleration

I've recently connected an MPG for jogging - it's connected to one of the encoder interfaces on a 7i76 card and - once I had the correct firmware in place - PnCconf detected it perfectly. I was also easily able to connect up a pair of rotary switches so I can select which axis to jog and the jog increment.

It all works just fine so long as the increments selected are small - 0.1mm or less, but if I increase to 0.5 or 1mm then the result is too "violent". I can calm things down by reducing the maximum axis velocity or acceleration in the .ini file but that affects the performance of the axis when running G code, so is not really a solution.

The jogging run using the Axis on screen controls has a separate maximum speed setting which is much more appropriate. I guess there must be a way for me to configure the jog commands from the MPG to have a similar, lower maximum speed to avoid the nasty, notchy movement I have with big increments, but I've not been able to fathom it so far.

Can anyone point me in the right direction please?

As an alternative to the low pass component, the limit3 component could be used to apply
lower velocity and acceleration limits to the jog steps

Yes, you're right, the MPG has one encoder count per "notch" or increment and 100 increments per revolution. What I really want to do is use this for moving the bed in both terms of fine and coarse positioning, so I'd like to know that one increment will be exactly 5mm, 1mm or whatever.

It comes as no surprise that the machine is using all its acceleration and speed to move to the commanded position - I'm effectively giving it a "G0 X5" command for each increment. What I'd like to do is give it "G1 X5 F500" instead, or reduce the maximum acceleration when jogging so it takes much longer to get up to speed.

Peters suggestion sounds like it might be in the right direction, but I don't know what "Limit3" is?

Thanks

Ben

Thanks guys - the example there does seem to cover it.

Now I just need to get my head around the difference between the example (using a parallel port) and my instance using the Mesa encoder input.

I can see that a lot is possible, but the learning curve is a little steep at times. However I'm sure I'm going to benefit from getting over this particular bump in the road just like I have done from all the previous ones!

Ben

Great, wonderful & fantastic!

I ran some tests in a virtual machine using sim-encoder to (simulate the mpg wheel output), ran that into encoder (to simulate the mesa hardware) then ran the output of that into ilowpass. Plotting the values of encoder counts alongside ilowpass output showed (once the scales were adjusted to show the detail) exactly what I was after - a rather notchy input being converted to a nice smooth output.

That part of the exercise was a really great learning experience - I feel that I understand the content of the .hal files much better now and I've found the best places to look up the description, functions, pins and parameters for HAL components.

Based on the simulated exercise it was quite simple to add the necessary lines into the .hal file to load & configure ilowpass, then add in one more signal to add the extra processing before sending the move command to the axis on my physical machine. The moves are now great - really nice and smooth, just how I want them.

Many thanks again for your help with this, all of you.

Ben