Advanced Search

I still maintain that no machine just to edit a couple of files or run a simple gui app is akin to driving a finishing nail in with a 100T pile driver.
SSH is the way to go, it doesn't require installation of a new package and doesn't require the running of a service mostly written in python if memory serves me correct.

The permissions for user CNC include group membership for gpio which is required. You do not need to change anything.
If you copy and paste the loading of the module from the man page it will work.
The problem was when you tried to load the module you inserted the word help. The driver wouldn't load because of "invalid parameter help".
Undo whatever you have done regarding udev. Reboot.
The permissions and group membership are setup whilst building the image.
Once again reread the man page, try loading the driver as shown in the example on the man page. If that doesn't work copy and paste the text on the terminal.
Remember with Linux that every character matters. Don't take any shortcuts and if something doesn't work as expected check what you typed and recheck your understanding of what should happen.

no of course, I apologize, but there is I believe a problem related to hal_gpio.
I read the man page and there were some discrepancies in my code, I was hoping the permissions fix from the man page would be the fix, but it wasn't

Good luck to all!

Thanks for your reply!

I went through the topic you referred to and it seems quite suitable for my needs. In essence, this is very similar to what the other commentator has suggested. But as compared to MPG these external offsets can actually rely on coordinated motion planners when modifying g-code controlled motion.

Now answering your question, this stream of coordinates is the only source of movement commands for the rotating platform. Hence, I can implement it the way the original author of the topic you referred to has done (i.e. 'M66' + 'G1' g-code commands in loop) or just issuing python/c++ MDI commands in a loop. In my understanding the algorithm might look like this:

1. Run G1 command in loop. Target point is the last available position received
2. If new data comes and the motion is still ongoing (e.g. check 'motion.motion-type') -> compensate the target position with 'eoffset-counts'
3. If new data comes and the motion has stopped -> signal to M66 input
4. If new data comes and the target position has not changed -> do nothing

The only thing I am not sure about is what would be my final position with offsets enabled. Say I finish one G1 command with the offset, and for the next one in the loop the same offset will still apply, right? So I have to set it manually to zero (e.g. with 'eoffset-clear'). Please let me know if you think it makes sense what I have written and whether you have any additional comments/suggestions. Thanks!

Both configs attached.  I included everything, not just HAL.

Thanks for taking a look.

Thanks for your reply!
The solution seems promising. I went through the code and I see how you control the axes using jog-counts like with MPG. The only doubt I have is that whether these jog-counts will respect the coordinated motion of XY axes. Say if I change both counts at the same time in my component, will it result in synchronous movement of X and Y and will it do proper velocity & acceleration/deceleration, or will it be just a linear motion with constant velocity? Please let me know if you have any idea. Thanks!