Remora - ethernet NVEM / EC300 / EC500 cnc board

scotta post=241746 userid=24854Roy, FYI I'm still looking at the following errors. Something really strange going on somewhere as the errors are consistently the same magnitude. I could test by increasing the max following error so that the program would keep running. The same magnitude following error spike on different joints. Makes me think it's something to do with DDS accumulator over flow that Rafal observed in the other thread. Anyway, Thanks for your help and patience.

Scott, Thanks for sharing that i was wondering id it was just mine. I am getting following error also. I have recorded what appear to be jumps in position FB from the NVEM that are consistently ~420, or ~60 counts. I have seen only these two values, in both directions, on all 3 axes. I decoded some packets to see what I could see and got some cool graphs like this:
 
Very weird. I modified my Remora-eth.c so that it does not update the accumulator on large sudden jumps. Instead I have it modeling feedback for the cycles in question to try and minimize position loss. Im going to test it out later today, but maybe it can help alleviate position errors until we can find the problem.
If there is anything I can do to help track this down let me know.
 

scotta wrote:

Hi,

You will know if you have a connection to the board when LinuxCNC will come out of E-Stop. This is the check for a connection. What is your output when you run ifconfig?

Thanks scotta,
i had no connect stop to 12V, now it is ok. 
after estop and machine on rs232 say 
## Entering RUNNING state
and now  I am able to change output pins .
Martin

 

spdbmp927: I have the same problem. But it looks like it's related to working on a laptop. High latency. Whenever he writes me a joint error. If I slow down, that's fine.

Hi Domi, when using the NVEM board latency of the PC is not an issue. The servo thread runs at 1khz in which a bit of jitter is not an issue. If the following error disappears when you slow down the motion then it would point to a configuration issue where the joint max velocity is not higher than the axis max velocity. So it cannot speed up enough to recover the following error.

FYI today I've received the stm32f437 and soldered it on the board. Changed the clock speeds, recompiled. Exactly the same behavior.

Hi, Roy interesting to know. I've been doing some investigation to try to understand where the spike (large delta) in the DDS accumulator is coming from. I was starting to think that it was due to the lack of a floating point unit in the F207, but if it's occuring in the F4 then it cannot be this as the F4 series has a FP unit.

I've got a version running which is updating the stepgen feedback in the servo thread, not every base thread execution. This allows for some debugging without crashing the MCU. There is something (rollover?) causing a large difference between two accumulator reads. I thought that moving to a 64 bit accumulator would solve this, but maybe my implementation is not correct. Still looking..

The spike could be filtered out, but this is a cheat. I'd rather understand the underlying cause and fix it.