Remora - ethernet NVEM / EC300 / EC500 cnc board

Hallo,
I did everything correct. when I press the estop in linuxcnc then I see the message "Bad payload = 0" in the terminal window.
Something is wrong with the ethernet communication, but what?
I also See no output on RS232, and there should be some output when you power up the EC500.
I installed the ethernet component via sudo halcompile --install remora-eth-3.0.c.
Is the board defect?
when no configuration is loaded to the board some LEDs are lighting, when I flashed the basic configuration then the conn blinks short and the LEDs from the output are off, only power LEds are on.
Any hint how to debug the problem?

==================================================
EC300 - XZ LATHE APPLICATION - JOINT-1 OR JOINT-2 FOR Z
==================================================
Hello,
I have my lathe moving in X and Z, with the homing also working. So far I am running with X/Joint0, Y/Joint1 and Z/Joint2 defined in the .ini file. I have tried to eliminate the Y-axis from from the .ini and .hal files but I found errors that I believe are due to Joint0 and Joint2 existing while Joint-1 is missing.
I have now moved on to verifying the working of the G54 Machine Coordinate System. In the AXIS GUI, once the X Touch Off for G54 has been entered, the Z-axis jog operation does not work, although the 'phantom' Y DRO coordinate ticks up to a greater value, and won't stop. I need to make a better job of defining the LCNC Joints.
There may be a short-cut in just connecting the Z-axis stepper driver to the Y-axis step/direction on the EC300 so that Z is Joint-1, although I would really prefer not to have these untidy connections (Z should connect to Z).

Is there a drawback or disadvantage to editing the ec300-rt1052.txt to swap step/dir pins of Joint-1 and Joint-2, for rerunning upload_config.py?
{
"Thread": "Base",
"Type": "Stepgen",
"Comment": "Y - Joint 1 step generator",
"Joint Number": 1,
"Step Pin": "P1_24",
"Direction Pin": "P1_31"
},
{
"Thread": "Base",
"Type": "Stepgen",
"Comment": "Z - Joint 2 step generator",
"Joint Number": 2,
"Step Pin": "P1_18",
"Direction Pin": "P1_25"
},

Joint 1 would be defined with STEP @ P1_18 and DIR @ P1_25, i.e. Z driver wires into the EC300 connection block for Z-axis.

Is there an advantage or disadvantage to removing unused AXIS/JOINT allocations from the EC300 .txt config file?
Would the EC300 physical connections be safely deactivated?
Is there any RT1052 processor advantage in doing this, e.g. unnecessary processing eliminated?

Thank you for everything on the forum so far, I'm enjoying the journey.

Hi Tim,

The Remora configuration allows total flexibility. So yes you can swap outputs etc. And I would only load the step generators that you need for your application.

Hi Scott, thank you for confirming the pin map reordering.
Much appreciated.

scotta wrote:

Hi Tim,

The Remora configuration allows total flexibility. So yes you can swap outputs etc. And I would only load the step generators that you need for your application.
 
 

 Hi Scott,
I have removed the 4 unused step generators from the config.txt file (X & Z remaining) and rerun the upload python script.  I have adjusted the .hal and .ini files to reflect this change.
Unfortunately there is now an issue where, although the X cross-slide and Z carriage move, the distance moved is ~1/20th of what it should be (and what it was before changing from XYZABC to XZ).
I have checked and rechecked the .txt, .hal and .ini files, wondering how perhaps the syntax for the [JOINT_?] and scale can have become corrupted, but found no clues to a cause.

Have you run Remora with less than the full complement of step generators without issue?
Does the ~1/20 factor suggest anything within the code around the step generators?

I have gone back to the original XYZABC config .txt and edited only the Y and Z joint numbers (now 'Y - Joint 2 step generator' & 'Z - Joint 1 step generator'; XYZABC Joints retained).  Uploading this with the python script makes the EC300 work as expected with measured axis distance equalling requested distance (with .hal & .ini unchanged from above).

Could there be a consequence of the total number of step generators running?

Hmm, the Remora step generator is blind to any scaling. It just receives a step frequency command from LinuxCNC (Remora component). So I'd be thinking somthing to do with the trajectory, axis and joint configuration.