Welcome to LinuxCNC.org

Getting seemingly random "Joint Following Errors" on my Y axis. Can't isolate with G-Code so far, routine will run fine then fail in another location.

I built a stepper system using Pico USC controller and Gecko 203v drivers, which simulates a servo system. Went through some initial headache tuning the PID values to get running smoothly without errors. X and Y axis utilize the same chain/sprocket drive setup, and identical PID values. Which is baffling to me because I am not getting errors on my X axis, which is carrying the entire gantry loads, while the Y axis is driving smaller loads. If there was a problem with acceleration values I would think the X would fail first trying to keep up.

Any ideas why one axis would fail and not the other one?

Jeff

A gecko 203v is just a stepper drive, I have several of them...

Did you run the latency test for an hour or three?

linuxcnc.org/docview/html/common/Stepper...html#_error_messages

John

Yes, I purchased an Intel D525M motherboard and installed a 60gb SSD based on recommendations from this forum. Latency max figure is 16000. I also purchased Pico Systems USC to help with demands of software step generation.

Jeff

Update -
This is an open-loop system without encoders, so obviously there is no way for the software to actually know what the axes are doing, so my comment on the X axis failing first was unrelated to what is actually causing the error. (I hope) I am using CAMBAM, and just getting comfortable with its interface and methodology so I think I may have come up with part of the problem. I thought I was running in constant velocity mode (G64), but noticed I was getting very inconsistent feed rates. I used the feed override to push things up since the cutter was doing quite well at this DOC. I think this was causing the machine to choke periodically, pushing beyond what the machine was capable of acceleration wise from a software point of view.

I went back to CAMBAM and ensured the constant velocity mode was set, and also increased the desired feed rate. Still not sure if CAMBAM actually does anything with that value or not, since it knows nothing about my machines acceleration and velocity capabilites. Anyway, when I did a dry run with the new code, so far, I think the results are favorable, (no errors). Just in case, I am going to dive into HALSCOPE and re-run some PID tests to see what tweaks I can make to tighten up the control loop.

Still baffled why I did not get errors in the X axis.....

Jeff

I don't know anything about the pico systems board or what it does so I'm kinda flying blind on that part.

A latency of 16,000 for a 525 is twice was is normal for that board... you might check to see if the bios needs an upgrade. I usually see < 8000 on my 525 or 510.

Did you read the link on software step generated following errors for steppers?

John

G64 - without P means to keep the best speed possible, no matter how far away from the programmed point you end up. If your making lots of small moves I'd suggest using G64 Pn to turn on the naive cam detector which will improve speed better than G64.

linuxcnc.org/docview/html/gcode/gcode.ht..._g64_path_blending_a

My guess is something is different with X in that software step generation doesn't get beyond the limits and trip the following error.

John

U2fletch wrote:
This can only happen when the requested pulse rate is faster than the machine can handle. It is quite common with software step generation, normally caused by the base thread period being too long relative to the requested step rate.
You have the Pico USC and as far as I know there is no way to hit the peak step rate of that in a real physical system.
However, there is a parameter for max-vel in the Pico driver setup. This has to be a little higher than the value in the LinuxCNC axis definition.

John, the Pico board does not use software step generation so that is completely NA. Did you read the Pico FAQ under the driver board section of this forum? It explains how this system works.

Yes, I was referring to G64 P, sorry just dropped the "P" when I was typing. I think this may be the main issue, so I am hopeful I have it under control now

You mentioned the latency numbers, I was getting numbers well below 8000 at all times until I ran gixgears, then it spiked to 16000. Are you running onboard video? If so then it looks like I do need to update my BIOS just to make sure I have the latest and greatest. Thanks for that tip.

Jeff

Jeff,

To be honest I've not read the Pico FAQ as I don't have one my self. I'm using a stock install and the onboard video. I do recall updating the bios when I first got the board.

Running glxgears and opening up a browser and my servo thread is still ~10k and base thread is ~13k. I don't care about base thread as I don't need one with the 5i25...

John

going to read Jon's FAQ now