Add headings and other geometric pins in motion using State_tags#3995
Add headings and other geometric pins in motion using State_tags#3995rodw-au wants to merge 29 commits intoLinuxCNC:masterfrom
Conversation
merge latest upstream into state-tags-arcs branch
merged to upstream
merge master to state-tag-arcs branch
…d read active_modes() in rs274ngc_pre.cc still ran the original unclamped loop above the clamped one, so the stack overflow into saved_settings[5] was unchanged. The line-number copy was also commented out. Drop the duplicate and restore the line-number copy. write_state_tag() still dereferenced block on the iscircle assignment (`block->iscircle = (block == NULL) ? 0 : block->iscircle`), reintroducing the M70 NULL-deref. Replace with a plain null-guarded read. control.c output_to_hal() read the iscircle bit out of `tag.fields[]` using the StateFlag index GM_FLAG_IS_CIRCLE, which indexes past `fields[]` (GM_FIELD_MAX_FIELDS == 8). Read it from packed_flags instead, like the update_status() copy does. Also dropped the duplicate interp_normal_heading write in the G2/G3 branch and restored the WATCH_FLAGS debug block to live inside update_status().
Round 2: re-fix M70 segfault and iscircle handling
M_PI_2 is a glibc extension and is not exposed by RTAI's rtapi_math.h, so the RTAI build fails with 'M_PI_2 undeclared' at control.c:2283. M_PI is available in both, so use M_PI/2.0 instead.
Fix RTAI build: M_PI_2 undeclared
|
Some observations:
|
|
Thanks for the feedback.
Ideas to resolve Item 3 would be appreciated. Just reviewing further, it appears #3924 that the ~/linuxcnc/configs folder contents have been added to the root folder on my PC. I don't think they have been included in this PR. Could someone please check and confirm? |
…that was not resolved when work commenced on this PR. 2. Deleted spurious arc_heading file. 3. Moved docs/man/man9/output_buffer.9 to docs/man/.gitignore
Sorry my fault, I forgot to add the generated man page to gitignore (#3941) |
|
Hm, I'm not sure I've been looking too good at the nc directory... Point Point 3 should be a separate PR, I guess. Point 4 needs to be solved by you taking the original file and only change what is necessary. |
|
Just to add a comment on nc files. It is not that you cannot or should not add (example) files. The point is that there needs to be some kind of docs or procedures that use or reference them. Just having files without people knowing how to find them is kinda pointless. |
You are not the first who gets bitten by this. There is a change in the works to let CI fail when this happens. |
As mentioned in the original comment, these new pins are documented in the motion man file eg Re point 2, you now see the problem with the nc_files folder caused by #3924 . I too only saw it it when the files were removed by git add. It was very wrong as it created the files that should have been under ~/linuxcnc in whatever was the current working directory. So saving the sim to your desktop created this mess! |
The man page is a reference for the component. These man pages usually do not do a lot of examples. For that we have the other documentation in the docs/src directory, where specific scenarios are described and more in depth explanations are (should be) presented. This is usually also the place, while explaining and going into depth, to reference the examples provided.
Yes, there was that unfortunate wrong side-effect while fixing the Tcl9 compatibility problem, sorry about that. However, it should be fixed now, isn't it? |
Man pages should find their way, yes. So does the other documentation afaik. |
in preparation to fix format errors caused by editor auto format options Aditional commit to follow
then reapplying chnagfes in this PR to it
|
Formatting issue in I can't see a clean way to correct the .gitignore issue by a PR from the oversight in #3941. Its been corrected in this PR. Re documentation, when I look at a the docs page on the web site, I can't see any chapter where additional documentation of a few extra pins is appropriate except for the man page. Perhaps these gcode samples could be deployed and mentioned on the man page but where do I put them so they turn up in the users nc_file examples? Adding example gcode for read only pins just does not seem right to me. The man page should be sufficient (as it is for every other component). All runtests pass I think this is now OK for approval. It is benign as it does not add any additional features, just exposes some useful information. Breakages are unlikely. Any fixes following user feedback can be added. |
sync local master branch to linuxcnc master
|
You still have the |
|
Corrected typos in comments. (1 was pre existing)
Thanks for everyone's help |
|
I had to force add Chips as it had been removed so restore failed. |
|
I don't trust Githubs tests, all runtests still pass locally |
Remove spurious inserted text in comments Uncommented "motion.jog-is-active" pin in motion.c
|
The problem with purely whitespace changes are that they are detractors from what is being changed. As such, it may be fine to change whitespace, but in a complex change it can become hard to keep track. (/me being pedantic) |
|
Yeh, I know you are being pedantic but as you say this is complex so I don't mind. Helps me learn. I did a git clean and rebooted but they are persisting. It can't be anything in that last commit surely. The only code I touched was adding back in the commented out pin. Any ideas short of recloning? |
I assume that this is just heading +/- 90 degrees. (I thought it might be pointless, but then realised that there is a +/- flip to consider) |
|
Then there is a problem in the exit procedure of the motion process. That can be because you have a crash that goes undetected? Run |
|
Thanks. Something odd. 44 tests fail and we only ever had 5 max before Luca helped me clean them up and I did runtests at my last commit and the output was still on the screen when I started tonight. Linuxcnc_debug.txt in home folder says |
|
What is in file in |
|
Hmm, so it says its an ini file thing but I have no idea where/if runtests has one. I check the env is set correctly for the rip path, |
You cannot depend on the files files in the home directory. Those are mostly not used in the tests. If unsure about RIP setup, run the tests from the src directory like You can specify the test you want to run like: |
|
hmm, looks like it is to do with enabling that pin |
|
rod@debian:~/devt/linuxcnc/tests/abort/feed-rate$ cat stderr
|
|
duplicate pin, deleted the one I uncommented; see what happens |
|
now passing. I must have copied that line down to use as a template when I had syntax errors with the pins |
Yeh, normally this angle would be from the centre out (which is calced to get the tangent) but this points from the path back to the centre so we can cut a bevel. I think a component could use external offsets based on these formulas So we could cut a countersunk hole. (the dxf that is used to generate the gcode would have the bolt hole and the outline of the countersink) so we'd use 2 operations and it would be all 2D gcode for 5 axis operations. I've recruited a couple of guys to help with this. Might end up with some components and sims once this is squared away. |
|
|
|
Also had a brief look about tangential knives. a voicecoil actutator with 5mm stroke is reasonabley priced so hook that to the end of a stepper motor to hold the knife and we should be able to vary stroke frequency with velocity so as it slows, strokes become slower... would be a pretty simple machine to make... |
I already looked into this a long time ago for kerf correction: |
Well that was a long time ago! I have been told water jet machines adjust the cutting head angle to allow for perpendicular cutting. Even plasma has a tapered kerf. I was thinking of countersinking with something simple like But external offsets would allow the cutting angle to be adjusted dynamically for kerf correction. QTPYVCP's Monokrom plasma GUI includes a material/machine SQL database I contributed containing high definition cutting parameters so it could be extended to include kerf correction for specific materials. The beauty is that it can all be done in 2D which avoids expensive 5 axis post processing and keeps the operator in familiar 2D territory. |
6 participants
Outline
create new [motion.interp.xx ] pins for heading and various geometric data (refer man motion for this PR). Note the following use cases behind this PR.
I am sure the community will find many other use cases.
Code notes
Caveats
We use the state tag motion_type (GM_FIELD_MOTION_MODE) to detect G0,G1,G2,G3 in motion. Currently there is no way to use existing interpreter equates for these values so the numbers are hard coded as 0,10,20,30.
RunTests
These pass locally
Acknowledgements
Many thanks to Luca Toniolo (grandixximo) for his encouragement and help resolving errors with the tests.