Feature Request

rodw wrote:

windows programming.

If we were programming in Visual Basic, I might be more helpful here. Used to write a fair amount of VB years ago for work. Python mostly just looks like hieroglyphics to me.

snowgoer540 wrote:

rodw wrote:

windows programming.

If we were programming in Visual Basic

I recall doing some stuff with that in a previous life.

Can I ask why you would like to unload a program. Is that what Pathpilot does or does it just clear the preview.

phillc54 wrote:

snowgoer540 wrote:

rodw wrote:

windows programming.

If we were programming in Visual Basic

I recall doing some stuff with that in a previous life.

Can I ask why you would like to unload a program. Is that what Pathpilot does or does it just clear the preview.

It clears the program, and the preview. It's like having nothing loaded, like when you first fire it up.

Maybe it's just become part of my work flow. On my mill, I have a box that I created with 5 buttons and an Arduino inside to emulate a keyboard. I use it for Start, Feedhold, Stop, Coolant on/off, and a button to go to the tool change position (G30). Eventually I'll make something similar for my Plasma table. I usually get into the habit of clearing the program when I will be messing around with changing over vices, etc. as sort of a safety assurance that I'm not going to accidentally whack the Start button and have the machine leap into motion unexpectedly. I also use it when I'm done running a setup on a part, and I wont be running the next setup until a bit later. A few times I've came back, loaded the part into the vice, found zero, and pressed start without loading the new program (like a moron). So now I clear the program so I remember to load the correct one once it's written/I'm ready to run the next op .

Maybe some of that wont be as prevalent in the plasma world, but it's also nice to be able to put it back to a "clean slate". I've found myself looking for a way to clear the program countless times since I've started the Plasma journey.

Did some testing of the new conversational, and noticed this:
When doing an outer cut, the lead in will be in the negative side of the cut area, that will end up with complaints of over travel or in my case since i have everything set at -30mm, it will trip the limit switch with a lead in longer that 3mm as that is what my machines back off of limits when homing, or start out of material.
That is for a square, so if the lead in would be from above, that would get rid of that issue.
This is an issue for users who use lower left as a reference, so any lead in should be to the right or above.
Otherwise it work magnificently, took all of 3 minutes to make a motor mount with slots. First time actually using it, that is why it took so long !

Feedback

Conversational:
1. After previewing (a rectangle, in this case), if I press send, it exits the conversational and places the "(new wizard)" and "m2" lines. The shape code doesn't come across. I have to press add before pressing send for it to work. Not sure if that is the intent?

Cut-Recovery:
1. Still some wonky stuff going on here. This time, I can move the torch around during the very first pause, but clicking "resume cut" doesn't get rid of the window, but the motion does resume.
2. If I pause a second time after pressing resume cut, the torch doesn't move anymore (like last night).
3. Clicking cancel has no effect at this point in the test, I have to click the X in the top right of the window to get out.
(I clicked Stop then, and restarted the job)
4. During the first pause, I am able to click cancel and the window goes away. I then resumed the cut and pressed pause again.
5. During the second pause, I am able to bump the torch around, and when I click Cancel, the torch returns to the paused position.

So it seems that it's something with clicking "resume cut" right now that it doesn't like this evening. On the bright side, pressing stop when it acts up seems to reset it.

tommylight wrote:

Did some testing of the new conversational, and noticed this:
When doing an outer cut, the lead in will be in the negative side of the cut area, that will end up with complaints of over travel or in my case since i have everything set at -30mm, it will trip the limit switch with a lead in longer that 3mm as that is what my machines back off of limits when homing, or start out of material.
That is for a square, so if the lead in would be from above, that would get rid of that issue.
This is an issue for users who use lower left as a reference, so any lead in should be to the right or above.
Otherwise it work magnificently, took all of 3 minutes to make a motor mount with slots. First time actually using it, that is why it took so long !

Thanks Tom, I did think about that originally but then decided not to worry because if it is an outside cut and a kerf width offset is then applied then the same issue would arise. I can revisit this if you think I should. There are a few othe shapes that start at the bottom as well that would also need to be looked at.

snowgoer540 wrote:

Feedback

Conversational:
1. After previewing (a rectangle, in this case), if I press send, it exits the conversational and places the "(new wizard)" and "m2" lines. The shape code doesn't come across. I have to press add before pressing send for it to work. Not sure if that is the intent?

That is by design (and in the user guide (although the button name has changed) ) If you don't add a shape to a job it is gonzo.

1. Still some wonky stuff going on here. This time, I can move the torch around during the very first pause, but clicking "resume cut" doesn't get rid of the window, but the motion does resume.
2. If I pause a second time after pressing resume cut, the torch doesn't move anymore (like last night).
3. Clicking cancel has no effect at this point in the test, I have to click the X in the top right of the window to get out.
(I clicked Stop then, and restarted the job)
4. During the first pause, I am able to click cancel and the window goes away. I then resumed the cut and pressed pause again.
5. During the second pause, I am able to bump the torch around, and when I click Cancel, the torch returns to the paused position.

So it seems that it's something with clicking "resume cut" right now that it doesn't like this evening. On the bright side, pressing stop when it acts up seems to reset it.

I don't see any of these issues here. If I press cancel the torch moves to where it was then the dialog closes. If I press resume cut (or the gui resume button) the cut resumes and when the torch gets to the original position the dialog closes. I can pause any number of times and it still works ok.
I am using your config with a sim hal file and randy.ngc as the gcode file. Have you tried with the torch disabled?

phillc54 wrote:

I can revisit this if you think I should. There are a few othe shapes that start at the bottom as well that would also need to be looked at.

Nah, i can live with it, just set the Y axis to back off 6mm when homing and i am golden !

phillc54 wrote:

That is by design (and in the user guide (although the button name has changed) ) If you don't add a shape to a job it is gonzo.

I should really re-read that I guess...

I don't see any of these issues here. If I press cancel the torch moves to where it was then the dialog closes. If I press resume cut (or the gui resume button) the cut resumes and when the torch gets to the original position the dialog closes. I can pause any number of times and it still works ok.
I am using your config with a sim hal file and randy.ngc as the gcode file. Have you tried with the torch disabled?

Weird. I am using job.ngc, but I think it's the same as randy.ngc (when I made the job for my coworker...Randy...I had two versions, I cant remember what was changed but I dont think it significant. I renamed the file just to keep them straight). Probably shouldn't matter a whole lot?

The testing I did this evening was with the torch disabled. In all honesty, the torch has been disabled for the testing I've been doing with regard to CR. My logic behind that was we should be at a point where it works with the torch disabled because most of the bugs would be squished before moving to live cutting tests, which burns material and consumables. Further I guess I was thinking that the torch disable or enable shouldnt have much of an impact as it likely just skips the torch fire and arc ok portion of running the g-code.
Maybe it's flawed logic, but it's worked thus far...?

I'm open to suggestion. It is odd that it behaves that way on my table but not yours. hmm....

Torch off testing is fine it shouldn't affect anything. I was just trying to find any differences between what we are testing.

I have a few other things to do today so I'll do some more thorough testing this arvo and see what happens. I just gave it a quick run through then and it all seemed ok.