forum.cncdrive.com

CNCDrive,

Having given up on the Xbox360 as a controller due to the 'jumping' problem, I just got a VistaCNC pendant in the hopes that that would eliminate the potential crashes the jumping might have caused, and I felt guilty wasting your and Eric's time trying to troubleshoot a problem that was likely a fault with my controller or system and not UCCNC or his plugin.

However, there seems to be a problem with the pendant or plug-in and VistaCNC indicates the root cause is with UCCNC and not their plugin or MPG hardware.

The issue is that in step mode, I can't rotate the encoder wheel faster than about 1 click per second before UCCNC stops responding to the MPG. Doesn't matter how high (or low) I set the jog % in UCCNC or on the MPG, it still quits responding. If I go faster - nothing. Back and forth - nothing. The only way UCCNC responds is if I turn one click, wait half a sec or more, click, wait, etc. Unbelievably aggravating.

VistaCNC's response to my question:

It is the UCCNC's design that in step mode the pendant dose not response
promptly. In some situation, fast PC and lager RAM may get some kind of
improvement. So, using small step size and high step rate in Step mode.


This is odd since everything works well in velocity or continuous mode - I can spin the wheel as fast as I want and it responds appropriately. Just in step mode.

My question is this - is there a latency or delay built in to UCCNC which limits the number of step signals per second (or unit of time) that UCCNC will respond to? Something only enabled in step mode?

If so, is there some way of decreasing the minimum time between step signals? I'm not trying to drive my table around at high speeds with step jogging, but if I move it in continuous mode within 0.125" of an edge it then takes me literally 40 seconds of click...click...click to get the edge finder or indicator tip up against a feature.

Any ideas?

Thanks much,
Spumco

Spumco,

Did you try MPG Multi mode? In MPG Multi mode every click is one selected step and you don't have to wait for the axis to stop between the clicks.

From the UCCNC manual:

In MPG multi mode when rotating the MPG wheel the axis is moving the jog step distance on all encoder ticks, the distance is selected with the distance buttons 0.001, 0.01, 0.1 or 1.00 Units.

As I understand it, the MPG features such as multimode are for MPG's connected to the BOB and used as a direct encoder. The VistaCNC MPG's are connected through USB and rely on the appropriate plugin to work.

I'm guessing a direct connection MPG would be significantly more responsive than anything working through USB, but what I'm experiencing is an order of magnitude worse than using the keyboard or pushing the step jog buttons on the Xbox360 using Eric's plugin.

Let me know if I'm wrong, though. It happens pretty frequently.

-S

Sorry, I thought it connects to the BOB. Then all depends on the plugin, I think. But, the best is the direct connection to the BOB.

Which pendant do you have?

VistaCNC iMach P4-S. It seems quite nice, lots of features. Feels good in the hand - not cheap or flimsy.

Velocity mode is super, continuous works too. Not sure yet about the function buttons as you have to do a double-click thing on the side 'enable' button for some things - it's not really suitable as a second (remote) controller unless you're holding it in both hands. You can't just reach over and dial the FRO or SRO or start/pause with a simple button or knob; you have to double click the enable button to activate certain features.

Downside is that the UCCNC plugin is very basic compared to the Mach3 version. There is nothing adjustable in the UCCNC version, but for Mach3 VistaCNC permits you to set all sorts of options - 9 user-programmable step values, FRO/SRO values, custom macro functions, axis reversal, etc. I'm annoyed the UCCNC plugin hasn't really been developed but considering the difference in customer base it's not that surprising.

Second biggest complaint is the step increments. Only values available are 1, 0.1, 0.01, and 0.001 increments. I can't select 0.0001 or type in a value on the flyout and have it recognized. This is almost a deal-breaker for me.

Biggest complaint is that it just isn't working for crap in step mode and I don't know whether it's a UCCNC problem, a plugin problem, or a hardware (mine or the pendant) problem. Whatever it is, it's aggravating.

I just want a pendant/MPG that works all the time and has a few features without threatening to ram a tool in to something or flaky when I try to use it in a reasonable way. And I'm out of inputs on my BOB, so I can't use a 'regular' MPG hooked up to the BOB.

-S

MPG stepping works simply with the plugin adding movement commands to the UCCNC.
In multi step mode the stepping happens per MPG encoder tick and in MPG single step mode the step happens on tick, but it does not happen again until the movement is finished.

What extra functions like function calls on button presses the plugin implements basicly depends on the writers of the plugin. I mean they could make a setup and call any button codes via the plugin.

And any size of increment is possible in the UCCNC, because it is the plugin who decides and send the movements, and so the plugin could send any size of movements.

CNCDrive,

Thanks, that's what I figured about the direct MPG encoder in multi-step.

The problem as I mentioned earlier is that UCCNC isn't responding to moderately fast encoder pulses from the Vista MPG when in step jog mode. If I spin the dial faster than one click (100ppr) per second (or maybe a half second, still quite slow) the axis doesn't move and UCCNC doesn't respond. The DRO's don't change - nothing happens. If I turn the dial very, very slowly, each step commanded is executed properly. There's no delay in the execution - it's not lagging - but over a certain step command speed UCCNC just stops responding.

I can see that if the step jog feed % was set very low and the step increment were high, then spinning the dial quickly might be faster than the time it takes to move the axis and the command to be finished. In that case UCCNC might not recognize the extra step commands as it was still executing the earlier ones. This is not my problem, however, as I have the jog feed set to 100%, and increments down to 0.001 - I should be able to spin the dial very quickly and have the commands executed appropriately with 'losing' step commands.

VistaCNC is claiming that this is a function of UCCNC and not their plugin. They were a little vague, but perhaps they're claiming that UCCNC refuses to execute step commands faster than some value. Do you have any ideas about this? Is there a maximum pulse or step command frequency that UCCNC can handle through a USB connection?

Thanks,
Spumco

In step jog modes as mentioned previously the plugin sends movement commands to the UCCNC and the plugin is responsible about what movement commands and how they sending them.
How fast you rotate the encoder and what is the resolution of the encoder the UCCNC has no idea about. The encoder counting is handled by the plugin without the UCCNC knowing or doing anything about it.
The only thing the UCCNC sees in this case is the movement calls and then it executing the moves which the plugin commands.

The question is which function call are the developers using?
They should call this function and then there should be no problem like what you described:

Code: Select all

AddLinearMoveRel(int Axis, double Step, int StepCount, double Speed, bool Dir)

This is a relative movement to the last point, it is like a G91 if talking in g-codes.
You can tell the UCCNC which axis to move, the size and numbers of the step(s) and the speed of the movement and the direction of the movement.

The issue might be if they executing motion with exec.Code instead of the above mentioned function, because that needs some time to compile the code string and to execute it.

In the plugin they use neither AddLinearMoveRel nor Code, but Callbutton. The plugin works by not the best technique.

Call button is like toggling a button press so the max button press speed is governed by the plugin loop speed as the button can only be high and low on each loop

They need to update their plugin to keep track of the encoder position between plugin loops and pass this info by the plugin to uccnc