Advanced Search

Appreciate the effort.

I've had a think, and I've got one more config attempt left in me before I quit trying to have a working C-axis.

Plan is essentially what PCW suggested in my other 'freewheeling' thread.  I'm going to abandon caxis.comp, and instead use orient as a 'bridge' between velocity spindle and position-axis modes so the c-axis doesn't error out upon reconnection.

Flipping between spindle & axis will use M-codes, and I think it can be done without any halui stuff so I can do everything within the same g-code program.

I'll start a new thread when I run in to problems with this attempt.

I  guess riju didn't need one that badly.

Thanks for getting back to me.  I am away from the workshop at the moment but I will do this test as soon as I return. 
Since my post I have adopted the default eeprom address 10.10.10.10  I have also set the PC to 10.10.10.11

If I type
mesaflash --addr 10.10.10.10 --device=ETHER --readhmid
The result is
Unsupported ethernet device 7i97T at 10.10.10.10

Thanks for your help

Wait is your big one set up as a 2.4 or a Trident? Eventually I am looking to build a 2.4 version with a 600mm cubed
work envelope (or bigger). Just not this round. LOL

Well, I had a good look and compared it to NoJo's config but I'm afraid I can't wrap my head around the problem.
If i understand spindle synchronized motion correctly then it really only depends on the encoder signals connected to the 'spindle.0.' pins.
I think the most likely way figure this out is to diagnose things with hal scope on the machine and find out what is happening to the index-enable signal and z-axis motion.
I'd love to help more but I have no hardware to test any of this.

You are absolutely right. I was extremely happy to see it run successfully
Now I need only connect the right PIN's since between hal_pi_gpio and hal_gpio the pin numbering is physical / BMC.

Anyway I appreciate your effort to help out
JAiro

Well that was embarrassingly simple not really why it worked previously without it but it seems to have fixed it.

Thanks

On the loadrt line you are trying to assign GPIO12 twice
loadrt hal_gpio inputs=GPIO3,GPIO5,GPIO6,GPIO4
outputs=GPIO12,GPIO23,GPIO16,GPIO11,GPIO20,GPIO10,GPIO24,GPIO19,GPIO21,GPIO12,GPIO26,GPIO13

The you have done this, trying to use GOIO12 twiceYou need to fix these issues
You may need to increase your base period over 10000, I tried 15000.
And as you did not supply your postgui_call_list.hal I had to comment out that line, to get everything to load.

These are my HAL and INI files:

drive.google.com/drive/folders/1ZyTfg1zN...FlzQlUXC?usp=sharing

that is remarkable, because I flashed the latest image for pi5 for the second time and double checked my HAL and INI files. (the 'help' was indeed misplaced, and set this discussion on the wrong leg)

This is my loadrt command:

loadrt hal_gpio inputs=GPIO3,GPIO5,GPIO6,GPIO4 outputs=GPIO12,GPIO23,GPIO16,GPIO11,GPIO20,GPIO10,GPIO24,GPIO19,GPIO21,GPIO12,GPIO26,GPIO13

I will try to attach my ful config below.

this is from the report:

Debug file information:
Note: Using POSIX realtime
Failed to register output pin collection
hal_gpio: rtapi_app_main: Operation not permitted (-1)
./my-mill.hal:7: waitpid failed /usr/bin/rtapi_app hal_gpio
./my-mill.hal:7: /usr/bin/rtapi_app exited without becoming ready
./my-mill.hal:7: insmod for hal_gpio failed, returned -1
4465
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

I ready that there is still tricky stuff related to get the pi5 going with hal_grpio, but I don't know exactly what it is.

kind regards,
Jairo

Couldn't have done it without you:

github.com/jethornton/flexgui/commit/5fe...6058577c6ff811b15ac7

Thank you for that commit!