Remora - ethernet NVEM / EC300 / EC500 cnc board

In EC500 controller I have burned one output (+ or -) and can not drive one axis motor.
Which IC must I replace?

jean wrote:

Hello, good afternoon. Could someone help me load the .bin firmware onto the EC500 RT1052? I've tried several programs and commands, but without success. I have the Chinese Stlink V2 and a Raspberry Pi Pico.
 

The EC500 does not like programming and I have bricked two controllers some time ago.
Fortunatelly this is possibility to bring it back to life. 
I have developed the following procedure:
1. Disconnect the controller from the power supply.
2. Disconnect the programmer.
3. Short by jumper the BOOT_M0 pin with 3V3 (programming connector).
4. Turn on the 24V power supply and do not turn it off until the end.
5. Remove the jumper.
6 Connect the programmer (I use ST-Link, but others also work).
7. Run the script below: 8. If it doesn't work, keep trying until you succeed.  

Hallo zusammen, könnt ihr mir bei folgendem Problem helfen?

Board: NVEM V5 (i.MX RT1052)
Getestete Firmware-Versionen: remora-rt1052-NVEM-0.2.1.bin, remora-rt1052-0.0.1.bin, remora-rt1052.bin — alle zeigen identisches Verhalten
Ping auf 10.10.10.10 funktioniert einwandfrei
upload_config.py sendet korrekt eine WRQ-Anfrage auf Port 69 (bestätigt per tcpdump), erhält aber nie eine Antwort vom Board
Keine Firewall aktiv (iptables ACCEPT), direkte Verbindung ohne Router

Gibt es eine spezielle Prozedur, um den TFTP-Config-Upload auf diesem Board zu aktivieren (Pin kurzschließen, erst einen Befehl senden, o. ä.)?

Vielen Dank schon mal im Voraus!

Hi,

I'm running into an issue and hoping you might have found a solution since posting this.

I'm using an NVEM V5 board (RT1052 chip). I successfully flashed the firmware via pyOCD 
(tried multiple firmware versions: remora-rt1052-NVEM-0.2.1.bin, remora-rt1052-0.0.1.bin, 
remora-rt1052.bin - all flashed without errors). Ping to 10.10.10.10 works perfectly and consistently.

However, unlike your case, I'm getting a timeout on my very first config upload attempt - 
not after a successful first upload. 
I've tried:
- My own custom config file
- The unmodified official example configs (both nvem-rt1052.txt and remora-rt1052-basic/ec500-rt1052.txt)
- Uploading with the SWD/ST-Link connection both attached and disconnected during the upload
- Confirmed via tcpdump that the WRQ packet is sent correctly on port 69, but no response ever comes back from the board
- No firewall involved (iptables set to ACCEPT), direct point-to-point Ethernet connection, no router

The script always confirms "Valid JSON config file" and calculates the CRC correctly, 
so it gets stuck at exactly the same point you describe - after everything on the PC side looks fine.

Did you ever find out what caused the board to stop responding to TFTP? 
Was it possibly related to the eStop/enable state getting stuck, as you mentioned the LED stayed 
permanently lit? Any insight into how you (or anyone else) resolved this would be hugely appreciated - 
trying to avoid unnecessary re-flashing if there's a known cause.


Additional update: I ran a UDP port scan to check the TFTP service status directly:

sudo nmap -sU -p 69 10.10.10.10

Result:
PORT STATE SERVICE
69/udp closed tftp

This is significant - "closed" (not "open|filtered", which is the typical ambiguous UDP result) 
means the board actively responds with an ICMP port-unreachable message. This confirms the 
TFTP service itself is never bound/listening on port 69 at all - it's not just that requests go 
unanswered on an otherwise-open port.

I also looked through remora-rt1052.cpp and noticed the TFTP server is initialized via:
IAP_tftpd_init(dmaThread->DMAptr->EDMA_Handle);
in the ST_SETUP state, right after loadModules(). This suggests the TFTP server initialization 
may never complete successfully during startup - which would explain why port 69 shows as actively 
closed rather than just non-responsive.

I've now tested every available NVEM-specific firmware (only remora-rt1052-NVEM-0.2.1.bin exists 
in the Remora-RT1052 repo) as well as the generic 3.1.x versions from Remora-RT1052-cpp 
(which don't even respond to ping on this NVEM V5 board, matching what "disneysw" reported earlier 
in this thread). I'm at the limit of what I can diagnose from the outside - any insight into the 
TFTP server startup sequence would be much appreciated.


Thanks in advance!

TANDEM Y AXIS CLOSED LOOP STEPPER MOTOR OSCILLATION WHEN IDLE

Hello all, 

threre is a stepper motor ticking issue going in my cnc mill that has been bothering me for a while now. I have devoted a fair amount of effort trying to "trial and error" my way out of it by playing around with tuning parameters but i cant reach a satisfactory solution, so hopefully someone here can provide some much needed assistance or reference to a similar case if the topic has already been covered before.

CONTROL SETUP DESCRIPTION
In my setup i use a rpi4b as the linuxcnc host along with an EC300 bob in which i have flashed the 3.1.3 version of the remora firmware for the RT1052 processor. Rpi and EC300 exchange packets over ethernet. 4 integrated closed loop stepper motors are driven by the the EC300 board using the corresponding STEP/DIR pins. Feedback from the motor's encoder does not reach linuxcnc so it essentially acts an an open loop system.

INITIAL ISSUE DESCRIPTION
In the capture5.txt i have recorded the following signals of J1 (one of the two joints driving the Y axis, the other is J3) in the servo_thread period while the joint reached the idle state after executing a jog command in my initial attempts to get my machine going.

1st column       : j1pos-cmd
2nd column      : j1pos-fb
3rd column       : j1freq-cmd

at the time of the recording J1 was configured this way (scale and the rest of the dynamic parameters remained the same to my current configuration) :

• remora.joint.1.pgain = 5
• remora.joint.1.ff1gain = 1
• remora.joint.1.deadband = 0.02

having all of the above parameters configured in the .hal file, the joint could not reach a steady state even though a single step equals to 0.0016 mm as you can see in the screenshot which is way below the deadband specified. The pos_cmd was constant but apparently a freq_cmd was calculated and sent to the EC300 that lead to the oscillation (how is that possible that the deadband gets defeated??).

CURRENT STATUS

In the attached .ini, .hal , remora-config-file.txt you can see how my machine is currently configured. Apparently by not specifying a p_gain and ff1_gain they both default to 1 according to the remora-eth-3.0.c  and with a deadband of 0.005 the Y axis is able to reach a steady state. The reason i am not satisfied is because the motion isn't smooth when approaching the final position, instead the motors "click" in place after a few steps and the axis makes a squeeking noise. When i try to modify the gain parameters to smooth the axis i roll back to the initial issue of not being able to reach a steady state. 

Probably i did a poor job explaining the chronicle of my situation but hopefully i ll be able to further clarify in follow up questions.
Thank you






 

Has anybody got G95 working with their remora setups??

iv got it working by setting lowpass-spindle-encoder-velocity.gain to true.

But how do I permanently set it to true. I tried setp in .Hal but it's getting overwritten every time I restart linuxcnc