Feature Request

Interesting approach, I see that it sends it back to the pause location now when you press stop.

The problem is the accumulated rounding error (I assume) is still too great. For some reason this effects my X axis more this go-round.

After I perform the steps to induce the issue, the X axis shutters worse than the Y axis, and I can rapid it right through the soft limit and trip the home/limit switch. On the right side, I ran it off the gear track :laugh: It gave me following errors at the same time.

Interestingly enough, for experimentation sake, I un-commented the "setp pid.x.maxerror .0005" lines and it seemed to shutter less (edit: I should say it shutters much softer). It still loses its spacial orientation though.

Attached a screenshot of the offset errors.


Edit: I learned that re-homing does straighten it back out. So at least I dont have to close and re-open all the time now while testing.

snowgoer540 wrote: Interesting approach, I see that it sends it back to the pause location now when you press stop.

Yes, it needs to clear the X/Y axis offsets

The problem is the accumulated rounding error (I assume) is still too great. For some reason this effects my X axis more this go-round.

I think it is the way floating point numbers are represented. Your shown offset-current values are X 0.00000007920926 and Y 0.000000001518594. I wouldn't have thought that would cause any issues but...
It seems this is an issue with the eoffsets feature. We cannot change the offset-current values, they are an output and are just informing us what the current actual offset is. There are axis.a.eoffset-clear and axis.b.eoffset-clear pins but I tried them and they make no difference.

Edit: I learned that re-homing does straighten it back out. So at least I dont have to close and re-open all the time now.

Interesting...

phillc54 wrote: Interesting approach, I see that it sends it back to the pause location now when you press stop.

Yes, it needs to clear the X/Y axis offsets

Just doubt I would have come up with that, I like it... simple, yet effective. Well I guess mostly.

The problem is the accumulated rounding error (I assume) is still too great. For some reason this effects my X axis more this go-round.

I think it is the way floating point numbers are represented. Your shown offset-current values are X 0.00000007920926 and Y 0.000000001518594. I wouldn't have thought that would cause any issues but...
It seems this is an issue with the eoffsets feature. We cannot change the offset-current values, they are an output and are just informing us what the current actual offset is. There are axis.a.eoffset-clear and axis.b.eoffset-clear pins but I tried them and they make no difference.

Wish I could offer some help here. It seems like such a small problem, but I guess it's a problem nonetheless lol.

Edit: I learned that re-homing does straighten it back out. So at least I dont have to close and re-open all the time now.

Interesting...

I thought so too. It sets all the offsets back to 0.

Any ideas why un-commenting the max-error lines made the shutter softer? I thought those lines didnt mean anything to a stepper system, or maybe I totally misunderstood and they really are necessary?

snowgoer540 wrote: Wish I could offer some help here. It seems like such a small problem, but I guess it's a problem nonetheless lol.

I am not sure that it is something we can do anything about. I'll have a bit of a look around and may have to ask on the developers list.

Any ideas why un-commenting the max-error lines made the shutter softer? I thought those lines didnt mean anything to a stepper system, or maybe I totally misunderstood and they really are necessary?

I only know what PCW described here:
github.com/LinuxCNC/linuxcnc/issues/910

I am not sure that it is something we can do anything about. I'll have a bit of a look around and may have to ask on the developers list.

Bummer. I wish it didn't potentially mean a crash if someone stumbles across it unknowingly. Hopefully they can shed some light. Maybe the eoffset-clear pins are messing up, and we inadvertently found a deeper bug??

I only know what PCW described here:
github.com/LinuxCNC/linuxcnc/issues/910

Smart man that Peter is. It's way over my head.

snowgoer540 wrote:

I am not sure that it is something we can do anything about. I'll have a bit of a look around and may have to ask on the developers list.

Bummer. I wish it didn't potentially mean a crash if someone stumbles across it unknowingly. Hopefully they can shed some light. Maybe the eoffset-clear pins are messing up, and we inadvertently found a deeper bug??

We don't actually clear the eoffsets, that would result in motion at the max velocity, what we do is bring the eoffset count back to zero at a rate governed by the F word. The rest is handled internally in LinuxCNC.

I only know what PCW described here:
github.com/LinuxCNC/linuxcnc/issues/910

Smart man that Peter is. It's way over my head.[/quote]
Mine too, I just follow along...


Could you try it with X and Y both set to 0.1

Could you try it with X and Y both set to 0.1

I just laid down to hit the hay, I’ll try it in the morning before I head to work... that said you might be on to something. I forgot I set my Y position for CC to Y1 during previous testing to see if it being away from the soft limit would help. X was still zero. Maybe that’s why Y seemed better and X didn’t?

I just laid down to hit the hay

Sleeping on the job, we can't have that.:laugh:

I pushed some more changes, better feed rate calcs, better error handling and also it will restrict the travel for consumable change to 10mm (0.4") from all limits.

I don't think it will affect the stutter issue but I have something for you to try.
When you get to stage that you see the stutter issue, back away from the limit then in Halshow in this order:

• put a watch on plasmac:offset-enable
• unlinkp plasmac.offset-enable
• sets plasmac:offset-enable 0

Notes:
two lines have a colon and one line has a period.
when you put the watch on, the led should have been on, then it should have extinguished when you did the sets command.

Now jog to the soft limits and see what happens.

Edit: you will need to net the plasmac.offset-enable pin to the plasmac:offset-enable signal to get the table to work again or restat LinuxCNC. (net plasmac:offset-enable plasmac.offset-enable)

phillc54 wrote: Sleeping on the job, we can't have that.:laugh:

Don't tell my boss that I didn't have time before work to check this out after all. I know bosses don't like excuses, but I'm dog-sitting for my sister, and they're less excited than I am to get up at 4:45am, much less go downstairs, do their business, and come back up in an acceptable amount of time.

At any rate, it gives me something to look forward to testing after work. Thanks for picking away at it!

I was unaware you could link and unlink pins in halshow....learn something new every day!

Maxerror lines should be omitted or deleted on stepper systems.
Using sensors as end stops is not a good idea, hard stops should be where your sensors are and sensors should be mounted sideways.