Thanks. I fixed it. I think it was a combination of sometimes doing M3 without an Sxx first on start up, then pressing the button (which defaults to S200) and then trying S100 M3 in the MDI.
Turns out I got the Analog 0-10V and GND wires reversed when I rewired the VFD.

The weird thing was with those wire reversed, it would not start the spindle below S175, but would only run the VFD at the max frequency with any S speed above that. So switch on, type M3 nothing, push button (= S200 worked but always at 70 Hz),  then I had been typing S100 M3, and it would not start. 

Switched the polarity, and now it is all back to normal.

I'll upload the latest HAL and Ini to the first posts a bit later, as it is good to have a back up here.

Really a cool milestone to make the first parts. Congratulations.

On my Maho I have:
HOME_SEARCH_VEL = 0

HOME_LATCH_VEL = 10

HOME_FINAL_VEL =15

Try a HAL with just this header in it... this works on my set of Mesa cards. You will probably need to change the IP address.

loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
loadrt hostmot2
loadrt hm2_eth board_ip="10.10.10.10" config=" num_encoders=5 num_pwmgens=0 num_stepgens=0 sserial_port_0=0000000"
setp   hm2_7i92.0.watchdog.timeout_ns 5000000
loadrt pid names=pid.x,pid.z,pid.s
loadrt debounce cfg=3
loadrt matrix_kb config=8x8



addf hm2_7i92.0.read          servo-thread
addf motion-command-handler   servo-thread
addf motion-controller        servo-thread
addf pid.x.do-pid-calcs       servo-thread
addf pid.z.do-pid-calcs       servo-thread
addf pid.s.do-pid-calcs       servo-thread
addf hm2_7i92.0.write         servo-thread
setp hm2_7i92.0.dpll.01.timer-us -50
addf debounce.0               servo-thread
setp debounce.0.delay         5
addf matrix_kb.0              servo-thread

Hello! 
Finally the wiring for the EXE and Mesa that worked for me:
I also dont need a extern  12V supply.

Mesa name  /   EXE Pin and colour
1 QA0         /     9  braun
2 /QA0        /     14 grün
3 GND        /      3 grün-weis
4 QB0         /     1 grau
5 /QB0        /     4 rosa
6 +5V          /     2, 6, 10 grün/braun
7 IDX0        /     7 rot
8 /IDX0       /     15 schwarz

And finally the references work! I only can drive the joints very slowly to find the index. Is there a way to drive faster? The index is only 0.001mm wide. sometimes it wont pick up. 

I also milled the first pices! It works great!



I have already recived the 7i74 und the 7i84U´s for the extentions.
On the weekend i will hook up these so i can use the diffrent gear for the spindle. 

This should be close

 


Note that I had to reduce the number of sserial channels to 3 to fit
(the are also renumbered so channels 0,1,2 are on 7i85 channels 0,1,2)

Most info will still work. The problem is that there is not really consensus about what automatic toolbit offset en height settings must do.
I had mine working for a while. I switched to 3d printing and will pick up later this spring.

Are there any potential drawbacks of this? I've wondered why this wasn't the standard implementation - I figured it was for good reason, so never asked. I ended up dedicating a physical button to activate MDI mode instead, but it feels like a waste of a button...

Will this modification switch back to MDI mode after a python based probing cycle (successful or failed)? I find that's the most frequent time I need to switch back to MDI mode.

Hello,

attached are the requested outputs and I added PDOs and SDOs outputs as well.

When working with multiple m codes, i always use Queue Buster before each m-code.
eg.

M66 E0 L0
M169 P9

M66 E0 L0
M169 P6
 

Is the info in this thread still relevant to QtDragon shipped with 2.9.7? I have a 3-axis cnc router with a manual change spindle and I'm looking to automate bit offset/height setting with a tool setter input on my 7i96s.

Don’t worry, I don’t know how often I intended to attach something and then just didn’t. I asked when I was still having problems with the PnCconf setup, so it is not relevant anymore. But thanks.

Yes, probably you are right... tomorrow next try

without knowing how and what you did its nearly impossible to guess, you appear to have been using multiple different old version to test or try things, so i would almost say for someone at your level your best bet is a clean build fro the ground up to ensure you don't have any remnants remaining that could muck up future progress.

Pretty sure yes... i got it to work now. But the latency of my new system is really really slow. I switch back to the old one. 

Last question for today...
" i would remove everything and reinstall from scratch using apt only, be sure to purge all installations"
what exactly i need to deinstall and which commands in the terminal?

If you measure the voltage across C36 I expect you will find a low voltage
instead of the expected 4.2V. What this likely means is that one or both
bus switch parts (74CBT16211) have been damaged by either ESD
or by being connected live to the G540 with no common ground
existing between the G540 and 7I92T before they were connected,
exposing the bus switches to a transient high voltage.