Help with QTplasmaC

phillc54 wrote: 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.

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.

rodw wrote: 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.

snowgoer540 wrote: 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.

rodw wrote:

snowgoer540 wrote: 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.

Ok back on topic

I now have a working config in that I can home all axis (not tried a test cut yet)

Q.1 Is it possible to use the keyboard for jogging ?

Q.2 in PlasmaC I used this coder for laser :
BUTTON_1_CODE = G10 L20 P1 X0 Y0 \ G54 G1 X -47.5 Y 21.296 F2000 \ G10 L20 P1 X0 Y0
I like the way this worked before. What do I put where to achieve the same result ?

Q.3 Is it possible to reset the GUI colour display back to defaults ?

Q.4 I am not sure where to put the THC encoder OV and 10V frequency's the docs says pncconf but I have altered my files so can't use that now.

Q.5 I think I read some ware that the DRO could be at the top of the GUI ?

Thanks for all the help.

Clive S wrote: Q.1 Is it possible to use the keyboard for jogging ?

Yes, it has to be anbled in the "Parameters" tab, "GUI Settings" part.

Clive S wrote: Q.2 in PlasmaC I used this coder for laser :
BUTTON_1_CODE = G10 L20 P1 X0 Y0 \ G54 G1 X -47.5 Y 21.296 F2000 \ G10 L20 P1 X0 Y0
I like the way this worked before. What do I put where to achieve the same result ?

Make another quick config and set it in Pncconf then just copy the laser line to your config.

Clive S wrote: Q.3 Is it possible to reset the GUI colour display back to defaults ?

Paste this into "HTML" box when selecting the color: #ffee06

Clive S wrote: Q.4 I am not sure where to put the THC encoder OV and 10V frequency's the docs says pncconf but I have altered my files so can't use that now.

Use the link to the calculator in the PlasmaC documents, not sure i have seen it for QTPlasmaC so might need to be added there.

Clive S wrote: Q.5 I think I read some ware that the DRO could be at the top of the GUI ?

Also read the same thing, no idea how for now.