Material Settings Glitch

Went boating for the weekend, so I didn't have a chance to try out the file with the number lines removed until now. It seems to work with the file you provided. I tried and tried, but couldn't get it to glitch like before. So seems probable that the line numbers caused the problems. At any rate, it seems like the latest update fixes that, so thanks again Phill!

Only one thing I did notice:
When you call the material that is already selected in the panel, it waits the full 2 seconds for some reason. I checked and double checked this, if I start with a material other than what will be called selected, it starts and cuts right away. If I select the material that is going to get called, it waits the full amount of time.

I have done some changes and just completed some testing that indicates we may not need to use the wait with M66, I have yet to have it fail using the immediate mode (M66 P3 L0).

I used a materials file with 500 materials and ran a gcode file with 20 material changes.

I will check tomorrow to make sure the changes don't break current configs/gcode and hopefully post them.

Well you can leave it at 2-3 seconds then. If M66 doesn't see a change then it waits for the timeout specified as Greg has discovered.

phillc54 wrote:

Well you can leave it at 2-3 seconds then. If M66 doesn't see a change then it waits for the timeout specified as Greg has discovered.

Makes sense about not seeing a change (because one isnt necessary).

What I dont understand is why the line numbers caused this to go bezerk in the first place? lol

snowgoer540 wrote:

phillc54 wrote:

Well you can leave it at 2-3 seconds then. If M66 doesn't see a change then it waits for the timeout specified as Greg has discovered.

Makes sense about not seeing a change (because one isnt necessary).

What I dont understand is why the line numbers caused this to go bezerk in the first place? lol

A couple of different issues, I guess one alerted you to the other because of all your testing of material changes.

I just pushed a fix for the delay, I had a couple of bits of inefficient code plus it now does a phantom material change if the material is already loaded. So you can either do either M66 P3 L0 or M66 P3 L3 Qn if you feel more secure with that. With 500 materials the maximum time to change was 0.16 seconds and both the M66 codes worked 100%.

phillc54 wrote:

snowgoer540 wrote:

phillc54 wrote:

Well you can leave it at 2-3 seconds then. If M66 doesn't see a change then it waits for the timeout specified as Greg has discovered.

Makes sense about not seeing a change (because one isnt necessary).

What I dont understand is why the line numbers caused this to go bezerk in the first place? lol

A couple of different issues, I guess one alerted you to the other because of all your testing of material changes.

I just pushed a fix for the delay, I had a couple of bits of inefficient code plus it now does a phantom material change if the material is already loaded. So you can either do either M66 P3 L0 or M66 P3 L3 Qn if you feel more secure with that. With 500 materials the maximum time to change was 0.16 seconds and both the M66 codes worked 100%.

Good deal, thanks for the work. I updated my Plasmac, but I can't currently test. My machine is down due to a sheared bolt. I need to pin the rails so it doesn't shear again. Unforeseen upgrade?

the save materials glitch seems to have reared its ugly head again:

Video Evidence For Investigative Purposes

I cant permanently turn THC back on, ohmic off, etc.

snowgoer540 wrote:

the save materials glitch seems to have reared its ugly head again:

Video Evidence For Investigative Purposes

I cant permanently turn THC back on, ohmic off, etc.

The way it works is:
If you display the default material when you press save all the settings on the run panel including the material will be saved.
When you have another material displayed then press save only the material parameters are saved and all other parameters are reloaded.