Help with QTplasmaC

Snowwy, nicely explained, thank you.

Clive wrote:

bevins wrote:

This has changed. I dont know when but it definately wasnt like that before.

Thinking about it . It might be a 2.8 - 2.9 thing

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

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.

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.

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.

Clive 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 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 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 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 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.