XBox 360 plugin update

[spumco]

Duh - 1.2042

Typed something random in and forgot to go edit it before posting.

Haven't been able to reproduce the step jog issue yet in v1.0004, but can repeat the axis direction change & jumping problems in all versions of the plugin.

As before, quickly reversing from one direction to another at 100% feed rate (joysticks pinned) results in the axis continuing to rotate in the original direction.

A quick test reveals the same thing is happening on the other three axis. The plugin configuration screen indicates both joysticks are sending correct plus/minus signals regardless of how fast I move them back and forth.

Just a stab in the dark, but changing the kernel frequency from 400 to 100 didn't fix this issue. The DRO's for all axis are responding to the unintended movements - when an axis keeps going despite the joystick switching direction, the DRO's report the actual movement properly. As before, I don't think this is UCCNC since the DRO's are correct.

Getting a little stumped here.

[Robertspark]

kernel frequency will have no effect on a plugin, totally different loop and it is fixed within the software on the pc.

the kernel loop is within the motion controller

why are you using a kernel frequency setting of 400khz anyway?, are you running encoders or high step rates?

Having a bit more of a think, what stepper drives are you using? The reason why I ask, is if you are shunting from one direction to the other, the kernel frequency setting will have an effect on the change in the status of the dir pin on the drive / axis.

Have you looked at the diagnostics page and the port and pin status to see if they are changing?

[spumco]

Robertspark-

I didn't really thing the kernel frequency had anything to do with it, but I figured it wouldn't hurt to try. I'm running at 400khz because it appears to run fine at that speed, and my spindle encoder needs it above 100khz.

Regarding the stepper drives, I haven't looked at the pin states but I would think that if they were acting up then UCCNC would not accurately register the movements on the DRO. Since there's no feedback from the steppers, if the drivers were not being commanded to continue moving in the original direction (after switching the joystick direction) then UCCNC DRO's would report a direction change.

That's not the case here. The drivers are being commanded to move.

[ger21]

What stepper drives are you using? Many will not work properly at 400Khz.

[Robertspark]

The drivers are being commanded to move.

If the drives are being commanded to move via the DIR pin changing state (high / low) then why would the drives not be responding

admittedly when you jog from zero up to the jog velocity, and then change direction, the drive has to decelerate, then the DIR pin changes state, and then the drive accelerates back up to the jog velocity.

Out of interest, do your drives decelerate and then accelerate?

If it's not apparent, have you tried reducing your acceleration setting? {just as a test to see if the acceleration + decel is more apparent?}

This may or may not work, but in the plugins tab, there is a plugin called "scope" it will show you the change in jog feedrate (the reason why it may not work is if your acceleration is too high it won't log the change in feedrate).

[spumco]

What stepper drives are you using? Many will not work properly at 400Khz.

The problem is still present at 100khz. Stepper drives are no-name Hu-Flung-Pu that came with the mill. 4.5amp-ish.

Settings are ~10,000 steps per inch, 150ipm max, 50in/sec2. Rotary axis set to 500 steps/inch, 1500units/sec, 150units/sec2 (corresponds with 5RPM for my worm drive).

Normal movements, from creeping a 'thou at a time to full rapid is fine. (Aside from the random 'jumping' I mentioned earlier in the thread.)

It's only when I rapid one way and aggressively reverse direction that the axis keeps going until I let off the joystick. Then it stops, and the DRO reports the actual movement - no lost steps or position error.

Out of interest, do your drives decelerate and then accelerate?

Yes. When I reverse the stick from one extreme to another, the axis stutters (decelerates and then accelerates) and then keeps going in the original direction. It does not come to a complete stop, just slows and then keeps going. The faster I reverse the joystick, the less it slows down. Very fast stick movements appear not to slow down at all, although I can hear a change in motor noise as the stick crosses the zero point.

I've not tried the scope plugin, but the xbox plugin has a display that indicates stick position, and UCCNC is seeing/reporting the stick change from left to right. The diagnostic LED's are indicating UCCNC is NOT changing commanded direction to the drives. When the axis slows and then keeps going, the original direction pin LED remains lit.

Axis acceleration - the rotary A axis is really, really soft now so I don't lose steps because I've got the backlash tightened right down. The X/Y/Z are pretty snappy at 50 units/sec2, but won't shake the mill when they take off or stop quickly. Setting the X axis acceleration to 5 or 10 makes no difference.

Jogging with keyboard - same thing happens if I jog with keyboard, sort-of. If I press the left arrow key (100% jog) and then switch very quickly to the right key, the axis continues moving in the original direction (same as with joystick). If I take my finger off the left key and pause for a brief period (<1 sec) then motion is as expected and the movement reverses.

It's like UCCNC needs a bit more time between commanded movements at rapid speed to register the direction change.

Running G0 X0 G0 X10 back and forth works properly. Same for all other axis.

Honestly, this isn't as big an issue for me as the axis jumping. I don't rapid back and forth all the time, and it's easy to avoid. The jumping issue is much more serious as it could ram a tool in to a part or wipe out my edge finder when I'm trying to sneak up on a part edge. It's interesting, and may be another symptom related to the jumping, but I'd rather solve that one before abandoning the Xbox in favor of an MPG. I have some expensive parts coming up and can't risk scrapping them due to a jumping mill.

Regards,
Spumco

[Robertspark]

I've not tried the scope plugin, but the xbox plugin has a display that indicates stick position, and UCCNC is seeing/reporting the stick change from left to right. The diagnostic LED's are indicating UCCNC is NOT changing commanded direction to the drives. When the axis slows and then keeps going, the original direction pin LED remains lit.

This sounds like CNCdrive needs to look at it as a potential bug or whoever wrote the plugin as it should change the status of the axis DIR pin when jogging from one way to the other or the axis will continue onwards (the STEP pins are just the step velocity to the drives, the DIR pin controls the drives direction).

Have you got backlash compensation set?

If so a potential issue was noted on the cnczone forum as a potential bug.
http://www.cnczone.com/forums/uccnc-con ... tware.html
{thought it may get posted over here and reported as a potential bug but its not happened yet, poster may be waiting for first post approval on this forum though}.

[spumco]

Nope. Backlash not turned on.

The direction pin changes when I'm jogging and reversing directions. It only happens when I move from +100% to -100% very quickly.

-S

[cncdrive]

I think the plugin mentioned here is not our plugin, but a 3rd party one, but if the issue happens also with the jog keyboard keys (the OP mentioned that it is) then it is definately not a plugin related issue.

It would be interesting to see the step/dir signals captured on a scope or logic analyser to see if the issue is really happening around the UCCNC or if it is something to do with the drives.
For example if they are servos or closed loop steppers then the jumping at high speed is an indication that the speed is too high for the drive/motor and the servo error buffer starts to run high, so when you stop or change direction then the servo error has to lower first and so a high speed jump happens which is then not an issue with the UCCNC, but the servo parameters or too high speed for the servos.
So, is why it would be good to see the step/dir signals measured to verify this potential problem cause.

Another thing to check is the Communication latency on the Configuration/Profiles/Statistics button to see if it is a communication problem, I mean to check if the communication time graph time jumps to the maximum when the issue happens? If it does then the issue is with the computer or the LAN card or the inbetween switch/router etc.
The UCCNC requires a max. 20msec latency to work properly, if the graph jumps to maximum is a problem and that could potentially cause the mentioned symptons.

The linked cnczone forum issue is totally different, it is because the comp.acceleration parameter is set too low, so the axis can reverse the backlash direction and compensate backwards before stopping.
Making the comp.accel parameter to 150%+ value of the normal acceleration should fix that problem.

[cncdrive]

And one more thing is that you can post your profile file and then we will try to reproduce the issue here.