Feature Request

2. Why was my ini missing the Y0? I am pretty relatively sure I never changed that. In fact I double checked Cody's ini file, and it is the same way (that's from a new config).

Only you can answer that.

I'm guessing the configurator makes it that way, since both configs are unedited in that area. Although since needing Y0 is an error and it misbehaves without it, I'd guess omitting Y0 was by design also

Only potential issue I see, is the torch doesnt go to the top of Z travel before going to change consumables. Probably hard for me to make a case for this if you are changing consumables, but there could be a scenario where there's a tip up, or you're cutting in box tube, or something where you'd want to retract Z before moving to change the consumables. Thoughts?

I thought that a pause caused it to go to the starting height.

The exact steps to duplicate: Pause on a rapid movement, between cuts (Where the torch is at the safe probe height). Click consumables change, it will move to the location with the torch at the safe height, rather than returning to the top of travel as with every other pause. Pushing Stop while the torch is in the change consumables position (X0 Y0) will cause the torch to retract to home in Z, before returning to the paused position. Alternatively, instead of clicking stop, and pressing change consumables again (from the X0 Y0 position) will cause it to go back to the paused location with the torch at the safe probe height.

Refresh my memory, did we change it so you could go forward and backward through the entire cut file, or does it still stop at the M3 commands going backward? I thought I remembered we changed that but maybe I'm making it up.

You can go forward the entire file and reverse as far as the previous M3. This is part of the "reverse-run'" feature and is not part of Plasmac.

I've been taking notes to remind myself of these sort of things for testing. Hopefully I remember this time. It can be easier to test when I know what the intended actions/outcomes are going into the testing, so it helps to keep a list.

It's doing the thing again where it shutters really bad when coming up against the home soft limit for Y. Seems to only affect the Y axis, and this seems to happen after I bump the torch around with the cut recovery window.

Can you describe the exact sequence of events to show this issue.
Are the offsets at zero?

The offsets were at zero. The offsets-current were not. However both X and Y had tiny offset-currents, and it doesn't do it to X.
One thing that I do notice is that when I use the cut-recovery to bump the torch around, the Y axis bumps around MUCH more aggressively than X does. Maybe that helps point you in a direction? I honestly cant get it to do it this session. I hate to prematurely say that maybe it had something to do with the backlash lines, but maybe it did? That wouldn't explain why Y movements during cut recovery still seem more aggressive though.

One thing I did note in you ini file is that you have a BACKLASH value in some joints.

Well, that's embarrassing. In all honesty, I was just messing around with backlash compensation awhile ago. I really thought I had taken those out. Oops. That said, thank you for the link and pointers on upping the accels and vels. I know the link says to up the values, but I always wonder why you need to. Maybe it's way over my head, but sometimes those explanations go a long way to understanding what is going on. At any rate, I commented the BACKLASH lines out. .005" of backlash on plasma probably isnt much to be concerned with. Thickness of a sheet of printer paper...

One last thing I noticed during this session:
If I press change consumables while the torch is in the middle of moving to X0 Y0, it returns to the paused location at rapid speed rather than the commanded feed rate (F160). Alternatively, if I wait for it to stop at X0 Y0 and then press change consumables, it will return at the commanded feed rate.

phillc54 wrote:

snowgoer540 wrote:

I'm guessing the configurator makes it that way, since both configs are unedited in that area.

Oops, my fault, for some reason that is what I put in the original sims.

One last thing I noticed during this session:
If I press change consumables while the torch is in the middle of moving to X0 Y0, it returns to the paused location at rapid speed rather than the commanded feed rate (F160). Alternatively, if I wait for it to stop at X0 Y0 and then press change consumables, it will return at the commanded feed rate.

Is that before the cut starts? If it is, it is because I didn't disable consumable change (we should call this CC to save wearing out my fingers) for the first and last rapids correctly.

No worries on the Y0’s disappearing act

No, it was definitely after the first M3, I think it was during the rapid between the right hole and the right slot. Definitely not on the first rapid (which works correctly and doesn’t let you click CC)

phillc54 wrote:

snowgoer540 wrote:

No, it was definitely after the first M3, I think it was during the rapid between the right hole and the right slot. Definitely not on the first rapid (which works correctly and doesn’t let you click CC)

I was a bit confused, so after a reread I think you mean if you press "CC" while it is still doing a "CC" move to X0Y0?

Correct, that causes a rapid back to paused position, rather than a feed rate move.

phillc54 wrote:

I think I fixed most of issues, plus:
Z goes to maximum height for a cut recovery from a rapid.
X/Y motion is slowed from the cut recovery buttons.

Good deal, thanks Phill! I'll give her a go after work today. Hopefully we got most of the bugs squished now!

rodw wrote:

snowgoer540 wrote:

Should have waited before pressing send.

One issue I missed:

It's doing the thing again where it shutters really bad when coming up against the home soft limit for Y. Seems to only affect the Y axis, and this seems to happen after I bump the torch around with the cut recovery window.

That sounds like either:

1. a misconfiguration issue with your Y axis. My guess is the machine is hitting a hard limit and the shuddering is when it misses steps. Or;

2. its missing steps and then hits the hard limit becasue it does not know any better.

Do you have limit switches? They should halt motion.

It may have been the accidental remaining BACKLASH values without increasing the ACCEL and VEL as instructed.

Otherwise, the table isn't missing steps, and would do the described during testing of a specific mode in a test branch of Plasmac. Also worth noting that I don't have hard stops, the shutter comes when it "runs into" the soft limit. There isn't anything to physically run into for almost 25.4mm (1.0 dinosaurs) at that point.

But I do appreciate the thoughts toward diagnosis!