Help with QTplasmaC
19 Apr 2021 20:18 #206470
by tommylight
Replied by tommylight on topic Help with QTplasmaC
Snowwy, nicely explained, thank you. 
Please Log in or Create an account to join the conversation.
19 Apr 2021 20:28 #206473
by snowgoer540
I upgraded to 2.9 on my main machine to do testing/help develop QtPlasmaC. I was on 2.8 previous to that, and this is how it was for me on 2.8 as well.
Perhaps it was a 2.7-2.8 thing? Either way. Use it to your advantage
Replied by snowgoer540 on topic Help with QTplasmaC
Thinking about it . It might be a 2.8 - 2.9 thingThis has changed. I dont know when but it definately wasnt like that before.
I upgraded to 2.9 on my main machine to do testing/help develop QtPlasmaC. I was on 2.8 previous to that, and this is how it was for me on 2.8 as well.
Perhaps it was a 2.7-2.8 thing? Either way. Use it to your advantage
Please Log in or Create an account to join the conversation.
20 Apr 2021 02:13 - 20 Apr 2021 05:17 #206493
by phillc54
Replied by phillc54 on topic Help with QTplasmaC
This is a bit OT from Clives thread but hopefully this will clear up some confusion.
QtPlasmaC was designed with the end user in mind. I don't believe that end users are interested in joints (well maybe some type of joints
) , all they want to do is move the torch left, right, forward, backward, up, or down. For this reason so I decided to hide the joints and only show the axes.
QtPlasmaC has no affect on homing and/or jogging, that is all controlled by LinuxCNC.
If a gantry machine is setup properly the tandem axes will have a negative HOME_SEQUENCE. LinuxCNC will not allow joints with a negative HOME_SEQUENCE to be jogged unless all axes are homed, for this reason QtPlasmaC shows the GUI jog button for any axis with tandem joints as disabled until the machine is homed.
If an attempt to jog is made using keyboard jog keys on tandem joints with an unhomed machine, it will result in a popup error message from LinuxCNC, I imagine the same error would happen for an MPG jog.
QtPlasmaC was designed with the end user in mind. I don't believe that end users are interested in joints (well maybe some type of joints
) , all they want to do is move the torch left, right, forward, backward, up, or down. For this reason so I decided to hide the joints and only show the axes.QtPlasmaC has no affect on homing and/or jogging, that is all controlled by LinuxCNC.
If a gantry machine is setup properly the tandem axes will have a negative HOME_SEQUENCE. LinuxCNC will not allow joints with a negative HOME_SEQUENCE to be jogged unless all axes are homed, for this reason QtPlasmaC shows the GUI jog button for any axis with tandem joints as disabled until the machine is homed.
If an attempt to jog is made using keyboard jog keys on tandem joints with an unhomed machine, it will result in a popup error message from LinuxCNC, I imagine the same error would happen for an MPG jog.
Please Log in or Create an account to join the conversation.
20 Apr 2021 08:38 #206510
by rodw
I'm with you on this.
Its interesting this conversation is still going on. When I first built my machine, V2.8 about 5 years ago, when the joint axes had just been released, there were a few bugs as people developing GUI's caught up with the new features and an attempt to jog Gmocappy in world mode would rack my gantry! So I removed Kinstype=both from my config, Norbert fixed a bug or two I reported and i never looked back. Then somewhere along the way, the ability to jog and home in world mode was added back in with some caveats.
I was a new user that never cared about being able to jog before homing or even new what world mode was. All I wanted to do is to home my machine and get on with life. I will say its handy to be able to rehome the Z axis. Kinstype=both is not in my vocabulary.
Replied by rodw on topic Help with QTplasmaC
This is a bit OT from Clives thread but hopefully this will clear up some confusion.
QtPlasmaC was designed with the end user in mind. I don't believe that end users are interested in joints (well maybe some type of joints
I'm with you on this.
Its interesting this conversation is still going on. When I first built my machine, V2.8 about 5 years ago, when the joint axes had just been released, there were a few bugs as people developing GUI's caught up with the new features and an attempt to jog Gmocappy in world mode would rack my gantry! So I removed Kinstype=both from my config, Norbert fixed a bug or two I reported and i never looked back. Then somewhere along the way, the ability to jog and home in world mode was added back in with some caveats.
I was a new user that never cared about being able to jog before homing or even new what world mode was. All I wanted to do is to home my machine and get on with life. I will say its handy to be able to rehome the Z axis. Kinstype=both is not in my vocabulary.
Please Log in or Create an account to join the conversation.
20 Apr 2021 09:23 #206512
by snowgoer540
Agreed. I took it out quite some time ago, and haven't looked back. Well, except to make an example post That plus making all my HOME_SEQUENCE values negative really prevents bone-head moves, especially where someone else might be using the table and have 0 understanding of soft limits, etc. Z on my table is quite fast, and therefore easy to crash when not homed.
These days, I also use VOLATILE_HOME = 1 (link) for each joint as well. I figure at this point, if I run into a limit switch, whack an estop, etc. the table should really be rehomed. This just forces me to not opt to skip it in haste.
Replied by snowgoer540 on topic Help with QTplasmaC
Kinstype=both is not in my vocabulary.
Agreed. I took it out quite some time ago, and haven't looked back. Well, except to make an example post
That plus making all my HOME_SEQUENCE values negative really prevents bone-head moves, especially where someone else might be using the table and have 0 understanding of soft limits, etc. Z on my table is quite fast, and therefore easy to crash when not homed.These days, I also use VOLATILE_HOME = 1 (link) for each joint as well. I figure at this point, if I run into a limit switch, whack an estop, etc. the table should really be rehomed. This just forces me to not opt to skip it in haste.
Please Log in or Create an account to join the conversation.
20 Apr 2021 09:49 #206515
by snowgoer540
Perhaps that does work from a relative standpoint in that exact scenario.
But also, consider that if you whack the hardware estop, the gantry might not be square anymore depending on how much twist you're pulling out when you home (I have mine basically stress free, but still).
Now that the eoffsets stuff is straightened out I don't think I've ever run into a limit switch, but in the past when that happened, I'd say most bets were off, it was time to rehome.
Replied by snowgoer540 on topic Help with QTplasmaC
These days, I also use VOLATILE_HOME = 1 (link) for each joint as well. I figure at this point, if I run into a limit switch, whack an estop, etc. the table should really be rehomed. This just forces me to not opt to skip it in haste.
I'm not sure for plasma that is a big issue because I always touch off to the laser pointer at the start of the job.
So my table moves about 19mm per motor rev or about 0.095 mm per 1.8 degree step. Worst case, you would jump to the nearest detent which is no more than 0.095/2 = 0.047mm from position or 0.002" in the old units. Its just not significant even if it jumps a few 1.8 deg steps! Once you touch off to the laser you are not going to have inaccurate parts.
Perhaps that does work from a relative standpoint in that exact scenario.
But also, consider that if you whack the hardware estop, the gantry might not be square anymore depending on how much twist you're pulling out when you home (I have mine basically stress free, but still).
Now that the eoffsets stuff is straightened out I don't think I've ever run into a limit switch, but in the past when that happened, I'd say most bets were off, it was time to rehome.
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.235 seconds