XBox 360 plugin update

[spumco]

CNCDrive,

The drives are not closed loop; simple stepper drives & motors, no feedback. This is why I'm pretty sure there's not an issue with the drives since UCCNC is reporting actual movement and not getting 'tricked' when the axis continues moving in the original direction.

There's no lost motion according to UCCNC - the axis are being commanded to move by UCCNC. Why they're being commanded to move is the question.

Checking the communication latency revealed no spikes or other jumps during axis movement. The plot was steady with minor peaks/valleys at about 1/3 maximum height.

I'm still more interested in the'jumping' problem. The jumping hasn't happened with keyboard jogging, so I'll try opening up the xbox controller and hosing down the contacts with cleaner. I'm not going to bother replacing the controller if that doesn't solve it (or we don't find a software solution). I'll have to abandon the xbox thing and get an MPG despite Eric's superb work on the plugin.

-S

[eabrust]

CNCDrive,



I'm still more interested in the'jumping' problem. The jumping hasn't happened with keyboard jogging, so I'll try opening up the xbox controller and hosing down the contacts with cleaner. I'm not going to bother replacing the controller if that doesn't solve it (or we don't find a software solution). I'll have to abandon the xbox thing and get an MPG despite Eric's superb work on the plugin.

-S

Hi Spumpco,

I'm still having a hard time visualizing the 'jumping' you describe. What setting do you have for 'velocity rate' in the plugin window (linear/squared/cubed)?

What the plugin is doing is taking the stick throw value (which is 0 to 1), and then scaling it to command a jogfeedrate percentage between 0 to 100%. the 'cubed' setting will provide the best low speed sensitivity, linear is the least sensitive for fine control. Turning on the 'trigger as velocity increaser' further makes control finer.

There is also a fixed deadband that stick movement must be exceed before jogging will start. I wonder if you are to near the dead band threshold and your controller is commanding jog to start/stop/start due to hovering to close to the deadband? If you a looking at the plugin window and watch the 'feedrate' value changing in the 'velocity rate' box as you exercise the joystick, do the values jump around, or increase smoothly? That value is what is directly sent to the jogfeedrate DRO and updated at plugin looprate to produce the variable speed jog, so if it is smooth, it isn't the calculated feedrate that is jumping, and would also clear the controller.

The plugin also relies on the slimDX interface to the controller, perhaps your controller isn't playing well with it? However, I would say that watching the 'feedrate' value change smoothly would also indicate if that is a problem.

regards
Eric Brust

[eabrust]

Gents,


Another issue (possibly related) I noticed last night while finishing a trunnion table build. While using the xbox controller to rapid the A axis, I moved the joystick to 100% and then quickly moved it to 100% in the opposite direction. The axis continued to move in the original direction until I released the joystick, and the axis DRO indicated no direction change. I can rapid rotate in either direction just fine, but if I don't let the joystick return to center for a short period the axis will continue in the first direction when the stick is reversed.

Thanks again,
Spumco

Balazs,

I played around jambing the keyboard arrow 'jog' buttons quickly, as well as throwing the xbox sticks back and forth quickly as Spumco described. I can confirm that on my setup (UC100, now running UCCNC2.045) that jog travel will continue in the first direction started, despite being commanded to go the opposite way with a rapid command change. In particular, the confusing one is the keyboard buttons doing it. This makes it seem like in the background, UCCNC latches onto keep jogging as long as it sees a button held down, and it is missing the queue to 'stopjog' an axis in one direction and 'startjog' that axis in the opposite direction. There seems to be some 'time' duration needed where no button press calling for a jog before calling opposite jog direction is made, or the direction change doesn't get triggered while general jog command stays triggered.

To be honest, it's not something I've seen or noticed before while using UCCNC or working on my plugin, as mashing buttons back and forth is bad practice. But in this case, I can replicate the result.

regards,
Eric Brust

[cncdrive]

Hi Eric,

Thank you for the clear explanation of the issue.
I have checked the same with the jog keys and I can reproduce the issue here.
I also debugged the issue on the UCCNC C# side and narrowed it down to the API, because the C# side of code is calling the proper jog functions, but really the API does not change jog direction if the keys are exchanged very fast.
So, I forwarded the problem description to my collegue who will debug the issue on the API side and will correct it asap.

[spumco]

Thanks guys. At least it’s not just me with the direction change issue.

As for the jumping best I can describe it is when i move the joystick slightly from neutral position the axis moves very rapidly for a small amount and the settles down to the intended very low feed rate.

[spumco]

And yes, mashing button back and forth is bad practice but in my defense I had just finished a complete retrofit and needed to beat the machine up a bit during commissioning.

[Robertspark]

It's not really bad practice, it is one way to performance test for lost steps / stalling and to tune your acceleration for jolt or jerk.

Admittedly I don't do it with jogging, but rather gcode program by zeroing a dial indicator, setting the home position, offsetting from the dial indicator a clearance distance, running a 100 or 200 line gcode file shunting the axis back and forth and then going back to the home position and rechecking the dial indicator, then doing the same with blended 2/3 axis motion.

You are at the end of the day just asking the machine to move at the speed and acceleration you've tested and set it to. If it has problems doing that, you have the wrong settings for your setup.

[spumco]

Rob-
Thanks. I figured “drive it like you stole it for the first 100 miles” wasn’t exactly a technical description of my commissioning procedure.
-S

[Robertspark]

describes my driving to a T
note locality >>>
At least it performance tests it to check the wheels don't fall off when you need them the most (don't mention wheels and scousers )

[eabrust]

I retract the 'bad practice' statement, wasn't well worded I agree it is a way to look for accel/velocity setting issues for setup purposes. I would lean towards a defined GCode vs jogging as Rob described.

Spumco, not sure what else to say with regards to the 'jumping' issue. Did you try to watch the 'feedrate' number being caculated as you move the stick with 'enable jogging' off and note if the numbers smoothly increase? Also, what is the velocity rate setting you are using?

regards,
Eric Brust / CraftyCNC