joshualee777,

Not sure if my Quick Reply was successful, so sorry for the duplicate post.

Hi! I've just successfully completed my initial test setup with a single JMC IHSV57. See github.com/rokoter/LinuxCNC/tree/main/ethercat/ihsv-homing . Hope it helps!

Launch LinuxCNC with cia402-ihsv-home-variant.ini
The Z startup error can safely be ignored

Yes, the value comes from the PID. My power amplifier is a -10/+10V. Is the value a voltage value? If the value is, for example, 17, I measure at the Mesa only 0.35V.

Hi! I've just successfully completed my initial test setup with a single JMC IHSV57. See github.com/rokoter/LinuxCNC/tree/main/ethercat/ihsv-homing . Hope it helps!

Launch LinuxCNC with cia402-ihsv-home-variant.ini
The Z startup error can safely be ignored

Yes, in the hal file, the analog outputs are all controlled by PWM values.

The actual PWM value shoudl be set by the output of a PID component that
in turn reacts to the difference in the encoder position to LinuxCNCs
commanded position.

It wont let you change the mode, its gets locked out. I gave up on getting probe basic to work

I've now loaded the standard 7i97t ini and hal files, and after a few minor adjustments, LinuxCNC is working (name, IP). In the hal file, I've only commented out the encoders and end positions for now, as they aren't connected yet. Is it even correct that the analog outputs are displayed as PWM? The only difference is that the value is set to higher values ​​(e.g., 17) when using the LinuxCNC interface.

@suremetall Yeah, that's what my thoughts are exactly. I could keep messing around with the original hardware, waiting for one thing after another to fail, but once this retrofit is done I should be able to run it for years to come.

The biggest challenge for me at this moment is the motor adapter for the z-axis (ram), which doesn't have a lot of space. 

I already created a design, but I'm having some issues with the tolerances and manufacturability I can't really get my head around. 

 

 

 

I have been using negative ref cycles setup ... everything works well, but I have been using native drivers with custom configuration ... latency is very low in my case

it is here ?  github.com/grandixximo/linuxcnc-ethercat

does your offset table show the offset for rotation column? if not you can set it to do so in the ini file by specifying the column axis as shown below:

 
 

check the qtpyvcp tutorials for buttons, the same method is correct for setting up user buttons in the user button ui

www.qtpyvcp.com/widgets/buttons/index.html

did you also add the addf and loadrt lines?

I am working on a new var widget that writes the var value to the widget at startup and monitors and updates the var for any changes without the need for running a subroutine. still in testing and will be released in the next major update hopefully!

I use Intel I225 with ec_igc driver, but I also tested generic and seems ok, I plan to do more extensive testing on something worse, just to see how bad I can go before I hit any issue, to have an idea on how cheap a system I can make lol.

The newest PR has not been merged yet at this time, you can get the code from my repo, or wait a few weeks for Scott, he mentioned he was going out of town.

I really think now the code respects the ethercat standard as closely as possible, it might just be a matter of exposing some phasing paramets for picky applications, but visualiziotion with halscope and sync0shift gets you all the way there too, and you have two options to choose from syncToRefClock true or false, if your latency is decent I advise to keep it false, with a refClockSyncCycles of 2, or 10 if you can wait a bit before start moving.

are you changing back to manual or mdi mode and is the probing routine your running completing and changing back after being in auto mode?

that is setting the work offset, not the tool length offset. if you have a tool with a store tool length offset in the tool table, and you load the tool with its offset active, and then bring the tool tip down and press z zero at the mdi, this will set the work offset to that height plus the tool length offset amount. once you set it for one tool, anytime you load a different tool and go to zero it should move the tools tip to the same physical height as the initial tool.

this requires all of the tools to have been correctly measured.