Feature Request

  • snowgoer540
  • snowgoer540's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
More
30 Jul 2020 00:40 - 30 Jul 2020 00:46 #176431 by snowgoer540
Replied by snowgoer540 on topic 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.
Attachments:
Last edit: 30 Jul 2020 00:46 by snowgoer540.

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 00:56 - 30 Jul 2020 00:58 #176433 by phillc54
Replied by phillc54 on topic Feature Request

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...
Last edit: 30 Jul 2020 00:58 by phillc54.

Please Log in or Create an account to join the conversation.

  • snowgoer540
  • snowgoer540's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
More
30 Jul 2020 01:04 #176434 by snowgoer540
Replied by snowgoer540 on topic Feature Request

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?

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 01:12 #176438 by phillc54
Replied by phillc54 on topic Feature Request

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
The following user(s) said Thank You: snowgoer540

Please Log in or Create an account to join the conversation.

  • snowgoer540
  • snowgoer540's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
More
30 Jul 2020 01:18 - 30 Jul 2020 01:19 #176440 by snowgoer540
Replied by snowgoer540 on topic Feature Request

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.
Last edit: 30 Jul 2020 01:19 by snowgoer540.

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 01:34 #176442 by phillc54
Replied by phillc54 on topic Feature Request

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

Please Log in or Create an account to join the conversation.

  • snowgoer540
  • snowgoer540's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
More
30 Jul 2020 02:12 #176448 by snowgoer540
Replied by snowgoer540 on topic Feature Request

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?
The following user(s) said Thank You: phillc54

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 05:38 - 30 Jul 2020 05:43 #176472 by phillc54
Replied by phillc54 on topic Feature Request

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)
Last edit: 30 Jul 2020 05:43 by phillc54.

Please Log in or Create an account to join the conversation.

  • snowgoer540
  • snowgoer540's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
More
30 Jul 2020 10:58 #176491 by snowgoer540
Replied by snowgoer540 on topic Feature Request

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!

Please Log in or Create an account to join the conversation.

  • tommylight
  • tommylight's Avatar
  • Away
  • Moderator
  • Moderator
More
30 Jul 2020 13:15 #176505 by tommylight
Replied by tommylight on topic Feature Request
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.

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.116 seconds
Powered by Kunena Forum