This toolpath is at centerpoint, so don't forget cuttercompensation. If G41/ / G42 makes trouble, whats not unusual, it can be solved like that. Parameter #5410 is tooldiameter of loaded tool. 
 

Yes, helix milling was the end goal. But I was trying to build the program as simple as possible to start with, because I have little experience with anything else than G0/G1. But I got stuck because the preview did not show what I expected for an in-plane (XY) circle.

Thank you for the explanation and test you provided!

Cam -> Raspberry PI3 -> 7Inch Touchscreen -> TCP -> WIFI -> LinuxCNC

www.youtube.com/shorts/sAEmJ-vLgHY
 

The output of the command "lcec_configgen" is usually a good starting point.

Just in case you want helix milling, you need to set z value for start and end. P is the amount of turns, if z-10 P5, it could look like that, pitch 2


 


 

The complete code was visible in the screenshot, but for clarity I include it here:
I made a new test with the code you used, and for that the preview is working properly. But if I comment out the G0 move, then the preview is again strange. See the two situations below.
 
 

The complete code, with G0 commented out is below:
Maybe this is expected behavior? It certainly wasn't what I expected, but that doesn't mean much. I use LinuxCNC 2.9.2 by the way.

Thank you for having a look. With that the issue is now pinpointed.

I am pretty sure I didn't make any changes to the .coreDC file.  What troubles are you running into? Ill post it anyway in case I did.

For step/dir, Mesa 7i96S is the right choice, and if you do need more IO add Mesa 7i84 with 32 inputs and 16 outputs and wires to 7i96S with a simple cut down LAN cable.

If need more I/O than a 7I96S can provide, a 7I76EU is a one card solution (basically a 7I96S+7I84U on one card)

I would like the same functionality.
I would like the setup page in gmoccapy to toggle the execution of MDI commands either by enter key, double click, button (like now) or by HAL signal.
But I did not have time yet.

This functionality cannot be simply implemented using the HAL pin in HALUI, because the EMC_MDIHistory widget is in Gmoccapy. So a new gmoccapy HAL pin should be created.

EMC_MDIHistory widget is here:
github.com/LinuxCNC/linuxcnc/blob/master...cp/hal_mdihistory.py

The function to confirm the command is here:
github.com/LinuxCNC/linuxcnc/blob/bf71ba...history.py#L151-L200

In gmoccapy.py:
github.com/LinuxCNC/linuxcnc/blob/bf71ba...py/gmoccapy.py#L3444

You can create new HAL pin in Gmoccapy for self.widgets.hal_mdihistory.submit()
linuxcnc.org/docs/devel/html/config/python-hal-interface.html

FWIW, I thought is was nice that pins are named stat_* in Donomik's version.

My mind was into naming pins after the mode they are used in. Problem being there are overlaps.
For example there are many velocities: Homing velocity fast, homing velocity slow, PV velocity,
CSP velocity, CSV velocity, PP velocity, all using different PDOs, except CSP and CSV velocity which is the same PDO.
I would guess also Probe velocity, probably several versions.

On the other hand, it would be a bit convoluted for the user to use .csp-commanded-velocity when they already selected csp mode and see it as natural to use .commanded-velocity.


 

I have installed linuxcnc 2.10pre on raspberry pi4. Now I want to update qtdragonHD to latest GIT version. Can anyone guide me how to do it?

@grandixximo 

Attached are the two NC files.

I'm not trying to dissuade you from using LCNC with an external PLC, but if you must have a physical PLC handling IO and similar...have you considered a PLC-only solution?

Some PLC's these days are available with high-speed outputs and built-in motion control (trajectory planner) functions.

I have built two automation machines recently using an Automation Direct ClickPlus PLC that drives three axes of coordinated motion via step/dir servos.  Programming was dirt-simple and the resulting motion met our expectations.

The main PLC has the HS outputs - no need for expensive daughter boards just to get the motion control features.

In my case the motion profiles are very simple; I've not explored the full capabilities of these PLCs... but if your needs are also fairly simple something like this might suffice.  Admittedly, the Click PLCs are fairly 'low-end', so higher-end PLC's likely have more sophisticated onboard motion control features.