Jerking in motion on same points of trajectory.

[cncdrive]

You totally missunderstood what I wrote.
Let me rephrase: The UCCNC is designed in a way that the steps summary sent out is the coordinates feedback to the DRO, there is only one multiplier between them the steps per value. This does not mean that lost steps can't happen, but it means that if lost steps happen then the DRO must be off with the steps lost or added and therefor this can be detected by the user. We designed the software this way on purpose, because if there is any problem with the motion planner or the pulse generator then that can be clearly identified. So, if you receive losts steps then you should verify if you command the machine to a known coordinate, let's say G0 X0 and then if the DRO is showing different than value 0 then the issue happened in the software/firmware otherwise if the DRO is the same then the issue is outside the software.

What I said in addition is that we verify the steps with counters before every official release to make sure there is no problem with these, because these are the most important part of the software, so we take the time to run long tests every time we change the motion API code or the firmware and we have never seen any problems.
Again this does not mean that there can't be a problem, but we do not see it.

[CT63]

We agree to disagree.. there is a bug with moving two axis with one moving towards the home postilion results in missed steps. It's not a power supply, driver or pc problem. Therefore I challenge cucnc to prove me wrong.

[cncdrive]

Unfortunately we do not see this, but will run some tests tomorrow and if anybody else see this please let us know, so we could build a pattern.
Also if you could check if the DRO differs right after when this happens and if you move to a known coordinate e.g. G0 X0 then if it shows X0 or different, it would be helpful to know.

[ger21]

there is a bug with moving two axis with one moving towards the home postilion results in missed steps.

Is this one missed step, or several? Or is it stalling? Is it audible?

"Moving towards the home position" is pretty vague, and covers roughly half the time that the machine is moving.

Does it happen only close to the switch or anywhere along the axis?

Therefore I challenge uccnc to prove me wrong.

Unfortunately, unless you can prove that it's happening, there's not much they can do. A random bug would be nearly impossible to track down and fix, especially if you're the only one seeing it.
Now, you say that you're not the only one? Have others reported this? Is it random for them as well?

The more information you can provide, the better the chance that the issue can be solved. So far, you've given very little information.

[A_Camera]

I had to work with the accelerations so it wouldn't stall. Keep in mind it may have been marginal with Mach as It is my first and only stepper system. It's underpowered for what I'm trying to do. What I was trying to point out is the planer is completely different. It's not like turning an input on and off. So converting from Mach isn't simply importing the old mach settings and letting it rip. You need to tune your system like it was new.

Perhaps I misunderstand you, but you make it sound over complicated, which is not. If you have a stepper based CNC running under Mach3 you can run it with EXACTLY the same settings under UCCNC as well. It will work just as well, in fact, even better, also if you don't do any tweaking. So, what sort of tweaking you had to do to make it work? Of course, since UCCNC has a better trajectory planner, you can tweak it so that it is EVEN better, but that is really not necessary, or am I missing something? UCCNC outperforms Mach3 in CV mode, and performs equal in exact stop mode.

Of course, I assume that you have had otherwise the exact same hardware, like the motion controller as well, otherwise it is apples and oranges... but if your motors stall under UCCNC they stall also under Mach3.

Since you seem to be an expert at these things I'll defer to you at this point.

I am no expert and never claimed to be, that's why I am asking questions. If you on the other hand want to be taken seriously you can't just say that a tweaking is needed when moving from Mach3 to UCCNC if you have a stepper based system without answering questions about what sort of tweaking you are talking about.

[A_Camera]

Ok... I've been beat up pretty bad over my post, not only from several members, along with told by CUCNC admins that missing steps because their "software is tested" and "can't happen", so I will pose the following:

Missing axis steps while moving in the direct to the home position on one axis when two axis's are moving, while running gcode does happen. I assumed it was a fluke but after 3 incidents it's not a fluke. I'm not the only one to experience this. It is a real problem.

I'm not new to the cnc steppers world as member Derek would like to you to believe, while I value his comments he is uninformed and making assumptions based on no facts to support his comments. I understand the multiple reasons why a stepper misses steps. I've been a long time advocate and supporter of uccnc... but to be told "it can't happen with our software" by uccnc reminds me of ArtSoft's attitude of screw the customer.

I hope this isn't cucnc's new business model to customer service.

I'd be glad to test run your G-code to see if it misses steps also on my machine. I would definitely not dismiss your claims since UCCNC, just like any other software, can contain bugs, but you can be sure that if we can show there is a problem with it then it will be fixed, assuming the problem is fixable in software or motion controller firmware. Yes, missing steps can happen for many reasons, one can of course be a software or firmware bug, but can also be caused by other issues, even if happened on three occasions.

The only time I experienced missing steps was during deceleration because I set the acceleration value too high for my machine after upgrading it. This was both with Mach3 and UCCNC and is not actually missing steps. The pulses are there but the motor stalled with a loud noise. The other time it happened when I probed the tool length and forgot to attach the probe contact, so the cutter smashed into the work piece and that stopped the Z while the DRO was updated in both cases. Also hitting limit switches can cause missing steps, or even worse, driving into the sides of the machine without even hitting the limit switches. But I guess these are not the situations you have problem with.

[A_Camera]

Fellows Derek has worked with UCCNC probably LONGER than most people even knew it existed. He designs and builds machines and parts that most can only dream about. His work can go from idea to machining casting core to casting and tehn Machining those castings into things like 4 valve per cylinder special cylinder heads for teh Z Datsun engines. He also designed and build the camshafts from scratch.

I would guess he has already built more parts than most will build in 2 lifetimes of DIY work (;-).

SO he just MIGHT have an idea about what he is talking about.

(;-) TP

...and the message is...?

[cncdrive]

Yes, missed or extra steps can occur in a stepper system from several reasons.
The one I've mentioned in my previous post is if the motion controller sends out the wrong number of pulses and that one type of problem is what I said is that it can be seen by the user,
because then the UCCNC would send the axis to the wrong position (position DRO offsets then). So, this was the first thing I wanted the user to check and verify to start somewhere to see where the problem lies.

There could be also other things which could cause lost steps, if we still only talking about settings or software related possible problems then the following things could also cause lost steps in a stepper system (I'm mentioning the stepper system, because some of these can't cause lost steps with servos), however I did not want to go further to checking these before we see an answer to the first mentioned possible problem.
So, the other things which could cause lost or extra steps (likely lost ones, but extras are also not impossible):

- If the set kernel frequency is higher than what the motor drive can safely read. This can easily happen with the ethernet controllers, because they support high, upto 400kHz kernel frequency which not all stepper drives can accept and read safely. So, it's a good idea to verify (datasheet of the drive should tell it) if the drive can accept the set kernel frequency pulses.
- If the acceleration parameter is higher than what the motor can do with the axis.
- If the velocity parameter is higher than what the motor can do with the axis.
- If the controller sends out higher velocity than what the user sets and which the motor and axis can do. (We verifing this though when releasing new APIs.)
- If the controller sends out higher acceleration than the users sets and which the motor and axis can do. (We verifing this though when releasing new APIs.)
- If the controller sends out the direction pulse with the wrong timing. (We verifing this though when releasing new APIs.)
- If there is a latency issue in the communication and the PC side stops to send motion commands then the motion controller has to stop the axis, because it runs out of data which stop happens with all axes deccelerating to stop. The decceleration happens with the Comp.decceleration parameter and if this happens and if the comp.acceleration parameter is too high can also cause lost steps in a stepper system.

So, it would be great to first see if the axis position offsets from the commanded coordinate or not when the issue happens, because if it does would narrow down the possible problems to a software bug.
If it's not then still anything could be from the above or if non of the above then there are still other things outside the software which could also cause lost steps, but what we can check and verify are the software related ones.

[Derek]

...and the message is...?

My message was based on my experience and to not ASSUME that it's a simple matter of converting the Mach settings over to UCCNC and then let it rip. Perhaps I was in articulate about it but you seem to speak in absolutes and that bothers me. I think it would behove people to import their setting but then set the machine up for UCCNC. Line by line. You tend to reply to people in a way that is very confrontational. It's about solving the guys problem but to you it's about winning the argument.

Did I give him great advice? Maybe, maybe not. But the next time I might have an idea about someones problem I'll probably hold my tongue rather than listen to the shade you and CT63 are throwing at me. You pollute the environment and stop discussion.


There I feel better now.

[A_Camera]

...and the message is...?

My message was based on my experience and to not ASSUME that it's a simple matter of converting the Mach settings over to UCCNC and then let it rip. Perhaps I was in articulate about it but you seem to speak in absolutes and that bothers me. I think it would behove people to import their setting but then set the machine up for UCCNC. Line by line. You tend to reply to people in a way that is very confrontational. It's about solving the guys problem but to you it's about winning the argument.

Did I give him great advice? Maybe, maybe not. But the next time I might have an idea about someones problem I'll probably hold my tongue rather than listen to the shade you and CT63 are throwing at me. You pollute the environment and stop discussion.


There I feel better now.

...and I was talking about MY experience of moving from Mach3 to UCCNC. Apparently my experience is not the same as yours and for that, I didn't belittle you or your experience, just wanted to know what you meant by "tweaking" and what issues you experienced. Apparently, that's a far too sensitive question for you to handle... so who is polluting the environment and belittling others?