Advanced Search

It is very unsettling when my 8k lb machine tries to walk around the shop floor and I know I'm not the only one with this issue as I have had this conversation with several others experiencing this issue.  I cannot tell for certain but it appears from your video that your machine probably weighs what one of the vises on my table weighs so it's likely not as big of a deal and hardly noticeable with such a low moment of inertia.  There are no settings in the cam softwares I've used that eliminate tiny line segments in adaptive tool paths which are a very large percentage of every part being programed in most scenarios.   These don't only occur at the end of a program but all throughout the adaptive cycle as shown in the case studies I posted previously.   I would think a trajectory planner that smooths out these segments to longer smoother tangent geometry will help this tremendously.   Coupled with s curve acceleration seems it would do wonders for these issues. 

You mention jerk control,  can you expand on exactly what that encompasses and how it actually would work if it's not an improvement of the trajectory planners function?   My limited understanding is that the real-time aspect requiring linuxcnc to be able to come to a complete stop by the end of a segment move, and this is what creates the stuttering.  It occurs while consuming consecutive small line segments and the velocity changes to allow a stop to happen based on the acceleration settings from the axis configuration and the commanded velocity being calculated with the segment length.  What will jerk control do for this and how would it be applied? I don't know enough about it to say if I think it's wrong or right,  but your statement of what areas are important to users I disagree with completely based on my experience over the past 5 years dealing with and desperately trying to find a solution to those phenomenon.   

From what I'm seeing here in the way of progress,  it appears these awesome contributors are on the right path.   Couple that with what tormach claims as an updated trajectory planner that is allowing their new mx1500 to gobble up high speed machining strategies smoothly and it certainly looks to me like all the ducks are marching in line.  

cool, thanks. once the bigger machine is alive I will revamp the little one.
right now i don't have any time or money to mess with anything. just trying to make parts to sell.

Anyone want a $2000 keycap set? hehehe

If the drives has optocoupler inputs. Its often a drive strength issue
which can be improved by wiring driving them single ended.
(as tommylight suggested)

If you just lose steps on reversals you might make the setup and
hold times longer.

Also as tommylight suggested you may have the step polarity reversed
which can cause direction setup time violations, so lose steps on reversals

I don't see anything obvious different about X but if you have poor network latency
(as suggested by the 1.5 ms servo thread period) you might try changing:

setp hm2_7i96s.0.dpll.01.timer-us -50

to:

setp hm2_7i96s.0.dpll.01.timer-us -200

Well I'm not messing with a working machine right now. But I will note these for later.

You have them wired differential?
Yes, swapping the STEP leads should work, but it can also be done in PncConf.
You might also want to try wiring the drives single ended and do a test, some drives work faster with greater voltage swing.

what do you mean by inverting? flopping the differential leads?

Hehe thanks

So, it should not be software, and it should definitely not be the mesa

But I'm also nowhere near the max specs of the drive either. Hmmmm. Under my DDCS control they ran are 18000rpm although its possible they skipped the odd step and i didn't notice. I never really used the machine under that control other than to mill 2 parts.

Mostly the question is for future thinking. when I get some delta drives that needs 500khz or more to feed them it will work.

Cr@p, almost forgot:
Very nice key caps
And try inverting the step output, on some drives it makes quite the difference.

ihavenofish wrote:

Step time/space is 20000 as I said. Lower than that it misses steps out.
The question is is this a mesa, linuxcnc or a servo drive limitation.

Drives, definitely and undoubtedly.
Strange...
Both LinuxCNC and Mesa can do much, much shorter pulses.
I have cheap drives doing 3000 without issues, ever, in several machines with 7i92.
I have a 7i96 (not S) doing 600ns with very good drives.
I have several machines with parallel port doing 4000ns
So no, not a limitation of LinuxCNC nor Mesa.

The screws are rated to 5000rpm. A screw not capable of 1200rpm would need to be extremely long for the diam.

Anyhow.
Step time/space is 20000 as I said. Lower than that it misses steps out.
The question is is this a mesa, linuxcnc or a servo drive limitation.

10mm pitch would imply ballscrews, so spinning those at 1200RPM is not healthy at all for them, depending on diameter and length, they start whipping much, much earlier. Might want to look into rotating nut setup.
The timings are set in the ini file, so edit the ini file for each joint/axis to a lower value for step time and step space, leave the dir timings at 2000 as they do not hinder performance. You can test lower values till you notice skipped steps or change in motor noise, then double that value.

Hello,

I just thought I would give an update. We managed to get one of the switches hooked up properly and the z-axis homing working. Woohoo! Thanks to everyone for their help and suggestions and taking the time to read my surely nonsensical ramblings. You helped me a lot.

I played with the motors a bit and set the y-axis motors to increase the stiffness in the fine-tuning which hopefully helps with some of the dots. It doesn't seem to vibrate much after we simulated the y-axis weight on the x-axis and did auto-tuning in the ClearPath MSP software and then copied the config to both of the y-axis motors. I'll try adjusting the I or the deadband after that process and see if that helps now because I only tried those before doing that to try and fix the vibration issue and it didn't work. Auto-tuning on the x-axis simulating the y-axis as best we could is what helped with that.

A note that for the LJ18A3-8-Z/AX inductive proximity sensor switch I hooked the black wire to the field input 8 which was the first available digital input. I'm not sure if 0-3 were digital because they weren't hooked up to anything. The other switches were hooked up to 4-7 and in a video I saw someone say they were capable of analogue so I used 8 instead. I thought I remembered reading something in the Mesa board manual about all of them being capable of analogue but maybe I'm not understanding something properly there which wouldn't be surprising. But it works like this so I don't think I'm going to worry about it. I hooked up the blue wire to the field power ground on the Mesa board and the brown wire to the power on the same orange field power block. This seemed to be the right way. The light on the switch is always on until it detects metal. This actually works.

Now, here is another big problem I was having. The MAX_VELOCITY for the z-axis was set to 0 in halshow. After spending countless hours trying to figure out why the z-axis won't move I started looking at everything in halshow and discovered that the others were at 116 but the z-axis was 0. I eventually traced it to a line the pendants hal file. There are some lines commented out for an extra axis but it uses the A axis. I realized one of the lines was for MAX_VELOCITY on JOINT_3 which is my z-axis and once I uncommented that halshow showed 116. I don't know if I need the other lines but things seem to be working from what I can tell so hopefully it's ok.

Another issue I'm having now is that I realize that when the machine is powered off or loses power that the z-axis falls down. I'm not sure if there's an ideal way to fix this yet but I don't want to wreck anything or anyone if the machine suddenly loses power for some reason. Who knows when the power could go out. When the x and y are at home the bit could potentially have something under it since it's over the work area still so I don't think it's ideal to just put a block of wood under it or use a little piece of wood to jam in the space under the spindle sliding part, like my dad was doing. Especially if I forget to put it in there which is quite likely sometimes. Is there any other way of dealing with this that I can implement in this particular setup? Or do I just have to code something to tell me when I shut the computer down to put a block of wood under it?

Thanks again!

So I have a machine that works fine, but the servos i have (ihsv57) have such a huge setup timing allowance (20000 from memory) that the top speed is being restricted to 12m/m instead of the desired 20m/m.

Is this going to be a function of my cheap steppers, or is this a function of the mesa card/linuxcnc? Or is there some setting if not done right that will tweak this.

The current math is:
10mm pitch screw, 4000 pulses per turn, at 12m/m = 80khz. the motors claim to take up to 250khz pulses.

Hmmmm

Lots of controls have better HSM motion than linuxcnc. many use splines etc. HOWEVER this does not directly have anything to do with jerk control. This happens a lot in discussions on the matter, people conflate the 2. In software I'm sure there is some intermingling of the functions, but as concepts we need to separate them.

The trajectory planner is I guess level "2" of the operation. Jerk control is level "1" if you will. Jerk control will tell the trajectory planner how it is ALLOWED to accelerate. Before 2.5 we hade a terrible trajectory planner. then we got the new one which put linuxcnc many notches above where it used to be, and above many other hobby controls. What is keeping it behind industrial is NOT that trajectory planner, but jerk control.

Once there is jerk control then it would be great to revisit the planner with deeper look ahead and other clever features to make HSM better.

Lcvette wrote:

Other controls that deal with cam output and smooth out motion don't suffer from these issues.   There are no settings currently that resolve said issues,  G64 helps but does not eliminate and only works in some instances.   A trajectory planner that outputs an adjusted tool path preparing motion into smooth curves and tangent arcs îs what I've found to be how other controllers function.