Feature Request

phillc54 wrote:

I was just wondering if the P1 variable is still also invoking mesh mode?

Sorry I forgot about that. Yes it is still valid.

Perfect. I want to do some hole testing as well, and some areas where I know previous jobs flamed out in an area where it was all but done with the cut anyhow.

Also, this mode might allow hypertherm users to use CPA mode with fine cut nozzles, I’ll test that too.

Thanks again!

The conversational tool is so cool now!

A few things I noticed about conversational:

1. The preview is in Metric
2. Over Cut check box cant be checked in the circle mode (stays greyed out)
3. The Conversational window stays on top of everything.. including this Google Chrome window
4. Y start starts at "-0.000" for at least rectangles. Probably doesnt make much difference but was just noticed it
5. I asked it to offset by the kerf width, but the produced code does not offset by kerf width for a rectangle.

The following options:


Produced this code:
6. "Nice to have" improvement idea... Can the pictures change with the settings? For example inside vs outside. Also, Start point (bottom left vs center)
7. I found it a bit confusing that I told it a start point of 0, 0, but it really started half way across the bottom leg of the rectangle (0, 19). I understand now what is going on, but maybe "zero point" or something is more prudent?

Separate because it has to do with mesh mode. I used mesh mode today! Man is this cool!

Not ignoring arc-ok on start (no movement)

Ignoring arc-ok in the beginning

So, I would say Rod's suggestion works great! If the video is shakey at the end, it's because it made me laugh. Sounded like someone was machine gunning over here!

One thing I don't understand:

At the end of this cut I received a Joint 3 following error. Joint 3 is my Z axis. I don't understand why it would have a following error because the THC is supposed to have been disabled and therefore the Z axis should not have been moving at all?

And finally, Cut-Recovery:

Not sure what changed, but seems like something did.

1. I see that CC is now disabled...correct?
2. Sometimes when I pause I cant use the CR window to bump the torch around
3. After I gave up on bumping the torch around, I pressed resume, and it ignored all of the M3's. It didnt probe at all. I noticed that even when I can bump the torch around, resuming the cut loses the Z motion. (mesh mode disabled, in case it matters at all)

Steps to reproduce 2 and 3:

• Home table
• Start job.ngc
• Pause during first probe
• This will still allow you to jog around with the CR window, however when you resume, it will not probe at the M3 commands
• Stop the program
• Start the program again, and pause during the first probe
• bump torch around (should still work) with the CR window
• press cancel
• resume cut (probing will work again for some reason)
• press pause again
• you will not be able to jog the torch during CR at this point, until you restart Plasmac

Last thing I noticed is that the CR window is dominantly on top (even this google chrome window) the same way Conversational is. Maybe not a huge deal except when you are reporting errors

Ok, I am sure I gave you a lot at once, I apologize. I did try to spread it across 3 posts because they were 3 separate portions of Plasmac.

Overall, I am super excited about these features! Mesh Mode was so cool, the conversational looks awesome, and I think the cut recovery will really add some finesse to recovering from a blunder, perhaps saving a piece of material. No doubt we will get it ironed out. Thanks again for all the hard work, I'm proud to be a part of this project.

The Conversational window stays on top of everything.. including this Google Chrome window

I didn't want it able to hide behind the GUI and to do that it needs to be on top of everything (I think, i'll search some more)

Maybe one place to look is HalMeter? I know that stays on top of LinuxCNC no matter what, but it doesnt intrude on any other windows. Truly only an issue when I'm trying to test and type to you on here at the same time

Y start starts at "-0.000" for at least rectangles. Probably doesnt make much difference but was just noticed it

It is 0.000 here, maybe when I fix it for that odd units system then it will be better.

haha you know I'll catch it if it doesnt!

I asked it to offset by the kerf width, but the produced code does not offset by kerf width for a rectangle.

I can emulate that here, it does work if you have a leadin. I probably should disable offsets without a leadin.

Why would one only want a kerf width offset when using lead-ins?

"Nice to have" improvement idea... Can the pictures change with the settings? For example inside vs outside. Also, Start point (bottom left vs center)

They could but it would be quite a lot of work. All those images are drawn in CAD (QCad for me), the master is saved as a dxf and the images are exported as png. So it would require an image for each setting plus all the python code to do the changes.

I figured as much. I may at some point in the future feel like volunteering to create them all, if you're interested. If you're not, that's ok too, I know it's likely a lot of coding.

I found it a bit confusing that I told it a start point of 0, 0, but it really started half way across the bottom leg of the rectangle (0, 19). I understand now what is going on, but maybe "zero point" or something is more prudent?

The points are related to whatever the coordinate system was when you opened the conversational.

I dont quite follow here. Before I opened the conversational, I set my 0,0 point. What I'm saying is rather than actually starting the cut at 0,0, it actually started the cut at 0,19. I think it's semantics on the word chosen, You're asking for the location of the zero point, but that is not where the torch will actually start.

At the end of this cut I received a Joint 3 following error. Joint 3 is my Z axis. I don't understand why it would have a following error because the THC is supposed to have been disabled and therefore the Z axis should not have been moving at all?

Well Z does have to move for probing, pierce height, cut height then finish height. I don't understand why you would get a following error though.

Oh, finish height! That makes sense. It never did return to finish height at the end of the cut. I did a little research, and Andy at one point told someone that following errors are usually a result of the servo thread not being fast enough. He suggested they calculate the frequency for the axis and compare to the thread and go from there. I understand what he's saying, I think. I will have to dork around with the calculations. For now, I slowed the axis down. 440ipm for Z is probably way faster than necessary. So I set it to 300 and chopped the acceleration down to 40.

One last thought: It wouldnt have anything to do with the arc-ok being overridden would it?

With the exception of circles all the kerf offset code in conversational uses gcode cutter compensation:http://linuxcnc.org/docs/2.8/html/gcode/g-code.html#gcode:g41.1-g42.1
Conversational is meant to be "quick and simple" and not a replacement for CAM. So I chose to do it this way as it keeps my coding simple and much shorter. To use cutter compensation it requires a leadin move greater the tool radius (in our case kerf width).

Oh, right, I actually recall this now from other things. Makes sense. To your point, if kerf offset wasnt an option, you could always manually do it, especially in the case of a rectangle by just making it undersized. I think it's sufficient to grey it out when it does not apply. I completely understand wanting to keep it simple.

I figured as much. I may at some point in the future feel like volunteering to create them all, if you're interested. If you're not, that's ok too, I know it's likely a lot of coding.

Yeah, we could have a look down the track.

Sounds good. I'll make note of it somewhere and see if it comes up again haha

I get what you mean now. So I should rename X start and Y start to X origin and Y origin?

I think that might be more appropriate, yes.

It "shouldn't"...

I'll be cutting some tomorrow, I slowed the axis down, I guess I can see if it does it again. But now that I think about it, I cant hardly believe that 440 ipm was too fast, especially when the others are moving at 1200 with more microstepping.

I'll probably be up for another hour or so if you need any clarification on the Mesh Mode (MM) and CR posts at all.