Advanced Search

Hi Guys,

I've re-controlled a Homag CNC router to use Linux CNC with MESA controls. It's was a complicated project, but for the last year it's been working well enough for me to be running commercial parts on it.

All of the motion hardware (mechanical / servos / drives) is what the Germans put in the machine 20 years ago. It uses Bosch ECODRIVE servo drives and has ball screws on x-axis and z-axis and a rack and pinion on y-axis.

The x-axis and z-axis work fine. The y-axis is "jumpy" when moving in the y+ direction. And smooth in the y- direction. I can clearly the position errors ramp up in halscope and then it appears to catch up and get back into position. With my hand on the gantry I can feel it jump / jump / jump going in the y+ and you can clearly see it in the tool marks. If I rapid at anywhere near full speed in y+ it will get wildly out of control and start slamming back and fourth and attempting to rip the whole 8,000 lb machine apart. But it rapids super smoothly in y-.

Mechanically the axis seems fine and there isn't anything like a dust collection hose that drags differently when going in a different direction. I've manually excessively lubricated the rack and pinion and it perhaps helps a little bit, but certainly doesn't solve the problem.

I recall probably spending about 10 hours attempting to tune the PID parameters and was never able to get it moving smoothly in y+. But I'm at the point now where I need to get it cutting smoother. So I am looking for any suggestions of things to try?

Thank you!

If I recall correctly I've PLL a fpga gpio at 50meg so to rid of that wizzy OSC extra part (im cheap, I know lol). If not 50M SPI then for sure it's full on 25Mhz and plenty capable kit. 

Doesn't matter, what's important to pay attention is something ain't right at 4Mhz, I suspect Lcnc won't be happy about that in fact. Perhaps the raspi is to be avoided if running on such a lazy tick?

I've added a few themes to Flex GUI. Notice the nice arrows on the spin boxes.

Blue Theme


Dark Theme


Blue Touch Screen Theme


Dark Touch Screen Theme


To add a theme you just add an ini entry.
gnipsel.com/linuxcnc/flexgui/ini.html#themes

JT

Aciera post=316563 userid=25994Maybe this documentation helps:
linuxcnc.org/docs/stable/html/user/user-...gramming-the-planner

From my experience the issue with the jerk is currently unresolvable, you can minimize it to some extent, but ultimately i have found no good solution to how the currently available linuxcnc trajectory planners handle modern code with short line segments and arcs and how the commanded velocity and acceleration settings work.  i think the only way to eliminate the jerk caused by high speed moves through short line segments and arc transitions where the motion velocity and acceleration rules come into play is to remove the realtime planner restrictions.  because the machine must be able to come to a complete stop by the end of the current or next move, it must change the machines motion to accommodate.  this means if the machine needs to be able to stop on a short line segment from a modern cam post output for adaptive clearing for example, and the commanded machine velocity is higher than it could stop when it gets to those short segments, the machine must decelerate to stay within the rule parameters. if the line segments are non uniform in length, the distance to stop requirement changes and the machine acceleration and deceleration is being changed very rapidly through each segment.  i find this is where i experience all of the violent jerky motion.  using G64 P and Q allows the motion path to make some of the smaller line segments into large line segments, but that just means there are fewer jerk points, not that the jerk is eliminated.  

I have pondered this and how it could be resolved, and I **think** it would require the rules be changed in the trajectory planner code.  I think a good compromise solution would be a calculation that uses look ahead and the machines acceleration settings and commanded velocity in conjunction with the planner calculating the path and setting the stop point to the next control point in the path that can be successfully stopped at under the currently commanded velocity and the deceleration configuration parameter setting.  if that means it requires 1 point or 1000 points to stop, it doesn't matter.

The example here being that to stop within the "1 point" would be where that point falls within the actual stopping distance for the machines parameters when the stop or feed hold command is issued, verse there being a series of very short line segments that may be only a few thousandths of an inch long), what would change with this method is the machine would maintain its commanded velocity through all of the path without having to slowdown for a "potential" call to stop.  this will give the machine the ability to move much faster and smoothly through the programmed path without the harsh acceleration and deceleration. 

In this regard the machine will always stop within the calculated distance of  (current velocity and deceleration rate + subsequent programmed point).  in this regard we are freeing up path velocity changes greatly which would result in much smoother motion.  the downside is the machine will stop a little slower in the event of a user call mid cycle.  

this would only change how quickly the machine stopped on those shorter moves.  because when the machine is moving at rapid or at higher feed velocities through longer segments or arcs, the stopping distance and time will always be the deceleration distance from the current velocity. 

just my thoughts, and i could be completely wrong, feel free to enlighten me if i am incorrect!  I will happily eat crow if it leads to a solution...lol

Chris 

Hi Guys,

i recently got one fanuc code and it has some Gcode for which I need help to find equivalent of these line in Fanuc for LinuxCNC. 
Please help me out with these codes:
1.  G5.1 Q1 R10
2.  G5.1 Q3 X0 Y0 Z0
3.  G5.1 Q0

Regards
Abhishek

i will check.
the mesa card should be wire with the ground ?

-no grounding
-bad/looped grounding
-bad/weak power supply
-error in wiring
-EMI/interference from drives/VFD
-PC with no ground connection
In that order, mostly.