Advanced Search

Thanks, I added dcconf lines (see attachment) but still get the same pin does not exist error

7I73 version 16 firmware

Increases the time between setting the row outputs
and sampling the column inputs( for longer cables etc)

Firmware:

 

SSerial update script:

 


 

I would first try setting the step time and step space to 5000 (5 usec)
since 2500 (2.5 usec) is the drives minimum (0 margin)

Also check the 5V at the 7I76U to make sure its not low

I think you need a dcconf item for every slave in the ethercat-cat.xml file.
I don't have exact syntax here on the phone, but search for dcconf and assignactivate 300 and there should be examples of that line.

Hi All
Please can someone suggest next steps to try to get this to work.
I am a novice at this, so it must be something obvious, it’s just not obvious to me

Please see hal, ini, io attached.
I have a gantry X Y Y Z (two y motors)
I am using a Mesa 7i92TM connected from P1 to a Mesa 7i76U.
I have tried latest linuxcnc images on both Raspberry pi4 and on Intel NUC, and get the same outcome.
I used current version of mesact

The Linuxcnc dro counts on the screen, but the actual motors don’t move.
It looks like It counts in all axis until the software limits are reached, then errors.
When switched off, you can move gantry by hand in any direction.
When switched on, the gantry is rigid.
Stepper drivers are all DM556T.
Green led shows on all four of the stepper drivers (no red led on any of them)
I have wired from 7i76u to stepper drivers in differential mode, and in single ended mode with common ground, it made no difference, no axis moved.
The watchdog led in middle of Mesa 7i76U is green, and flashes approximately every second.
I have four inputs. Limit switches on the x and z axis, and proximity sensors on both ends of y axis.
In halshow, all four inputs are yellow, and go red if you trigger any of them.
Please can you suggest where to look next, or what config changes to try.
Many thanks

The problem is a bit tricky to explain.

The Python upload script doesn’t show any issues — the problem only becomes visible when connecting to the board via serial port (RS232). On page 215, I described the core issue: the board rejects the new config with the message “JSON Config file CRC incorrect”, even though the CRC is actually correct.

When I initially prepared the board, I uploaded the “basic” EC500 config. This version uses the stepgen module on the BaseThread, which runs at 40kHz. That frequency was too low for my AC servo setup — I could only reach about 2400 mm/min feedrate.
So I tried uploading the DMA-accelerated stepgen config, which supports ~500kHz and lets me reach 6000–8000 mm/min. However, I couldn’t upload this new config due to the CRC issue.
Eventually, I erased the entire chip, re-flashed the firmware, and uploaded the DMA-based config again — and it worked without errors.
But when I tried to modify the config afterwards, the issue came back.

My theory:
The firmware stores the received config on the external NOR flash. After writing, it checks the validity (CRC) — and if it’s OK, it copies the config to another flash region and marks it as "Saved". It also erases the previous area (which is necessary for NOR flash writes).
However, if for some reason this copy/erase process doesn't happen correctly, then the new config can't be written to flash.
There’s no visible error, since the flash still contains data, but the system ends up checking and using the old (cached) config instead.
I’m not sure if I’m right, but it would explain the behavior. 

Do both Y have limit/home switches?
They must be set in the wizard for each Y.