ENH: Plasma Moving Pierce

[joco-nz]

Adjustments to support ramping pierce and a wiggle pierce as supported by sheetcam.

Capabilities for a ramp pierce:

1. pierce motion delay. Move in x/y but not in Z
2. Z movement ramp down to pierce end height
3. delay time before commencing movement to cut height. This should just be letting the remainder of TOTAL Pierce Delay run out i.e. Pierce Delay + Cut Delay

In parallel there is a speed profile in the potential sequence A. Gouge speed for gouge time period B. Crawl speed for crawl time periof C. Cut speed - should returning to normal feed rate.

Capabilities for wiggle periece: Supports x/y movement dueing periece delay. Under sheetcam wiggle code the time of delay should be long enought to allow the back/forth wiggle movement on the line of the straigh lead-in to complete the desired cycles at the feed speed.

[joco-nz]

Please advise what extra info/details/changes are required.

Regards - James.

[phillc54]

Thanks for this. Some terse comments on the M159 lines in the ngc file would be really nice along with an imperial ngc file. There are several occurrences of trailing whitespace in M159. A few typos: "perice", "whrn", and "moton" in M159 and the comp. The only issue I see is that match case requires Python 3.10 which not all users may have as yet. If you have any documentation that we could add to the QtPlasmaC doc it would be appreciated.

[joco-nz]

Thanks Phil - will get on to those. I will see what I can work out from a qtplasmac documentation angle as well.

[joco-nz]

@phillc54 I have pushed some fixes for typos, comments and a sub 3.10 working version of M159. I have also done an inital version of Moving Pierce documenation addition for QTPlasmac. I have one typo fix on it (1-Wiggle fixed to 1=Wiggle) and will continue to do a few more proof reads. If you see anything sing out so I can correct and push (hopefully) a single fix).

[phillc54]

Thanks James, I should get a chance to look at it this arvo, failing that it may not be until Thursday morning. In the meantime, adding this extra M code has made us think that the current M190 and this new M159 should be together somewhere more aligned to the HAL component rather than a GUI so we intend to move it/them to nc_files/plasmac/m_files. If you want you could put M159 in that location now and change the USER_M_CODE in both the existing sim .inc files to ./:../../nc_files/plasmac/m_files or we can do it later when we move M190.

[joco-nz]

@phillc54 - re the M159: is absolutely plasmac aligned not QTPlasmac specifically aligned so absoluteltly agree with the thinking and very happy to move it.

[phillc54]

I managed to find some time... Attached are some suggestions for the document. The rest seems OK, just need the comments in the metric .ngc file and I am not sure if you meant to leave in the print("Running M159") line.

pr2858.txt

[joco-nz]

Thanks Phil. Will fix those items itdentified. I also greatly expanded the content specific to the Ramp pierce in an attempt to really show what was happening and how the various values interact.

I have also done the move of the M159 file as suggested.

[joco-nz]

@phillc54 I believe I have the identified corrections covered now.

If there is nothing else that comes to mind let me know and I will move this out of draft.

Cheers.

[phillc54]

I am not really sure what is happening here but I am unable to apply this as a patch now, attached is the result. Maybe worth trying to squash all these commits into maybe two commits, one for the component side of things and one for the qtplasmac side of things.

[joco-nz]

It needs to converted from a draft state. I will do that and let you know when done.

[joco-nz]

@phillc54 It is now moved out of draft and should be available for merge.

[phillc54]

Weird... if I use the --reject option it does apply but it leaves M159 in the incorrect path. Apart from that it looks good, thanks again for the doc that looks great.

If you squash the commits down then I think it is good to merge.

[joco-nz]

@phillc54 - Ok squashed the commits. I'm not sure its done what you want. We are now past the edge of my git experience. I don't normally squash commits, hence in uncharted territory.

[joco-nz]

Closing pull request per conversation with @phillc54 due to issue being experienced on merge attempts. Agreed plan is to reopen using either a new branch or the pull request against the single rolled up commit.