Remora - ethernet NVEM / EC300 / EC500 cnc board

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.

 

I'd enabled the FPU indeed in the project settings. With the gcode I've got that quickly creates a following error (that I'd posted), when I replaced all feeds to the highest number (F2000) it seemed to do better. I've also tried another gcode with F7000 with only a few lines beacause it's using arcs that ran without a problem. Not sure yet if it's because of less lines of gcode or not so much using the 3 axis together. I'll do some more testing.
I was thinking could the cause of the spikes be a result of the buffer is being overwritten?

I've also seen there is a async udp library that seems to be faster, but I've no idea how I could implement that and if it could help.
github.com/khoih-prog/AsyncUDP_STM32#why...yncudp_stm32-library

Working through the problem a bit more, with more questions than answers. I've coded a version of Remora that uses 64bit DDS accumulators and changes the LinuxCNC component to receive the incremental accumulator (delta) between two servo periods rather than the actual accumulator. What this has shown is that it is not related to the roll over of the DDS accumulator. It's bringing me back to the floating point operation where the frequency command is scaled to the accumulator "add value". In the debug output you can see the massive jump in the accumulator during the servo period.

 

As I was reading this article, it seems that with some code combination the compiler it doesn't treat it as a float: mcuoneclipse.com/2019/03/29/be-aware-flo...s-on-arm-cortex-m4f/

So is it possible while I enabled the fpu it still did it in software? Or could that not be the issue eitherway? As the fpu only do float and no double.
I was looking into the source to see if I could recognize it, but I've not the knowledge to see if that's the case.

Can you help me with this doubt? I would like to know what sets the value for int32_t threadFreq? where do i get the value to assign to this variable? I'm studying about the implementation you used "dds" and I noticed and I couldn't understand very well when I came across this part, "this->frequencyScale = (float)(1 << this->stepBit) / (float)threadFreq; , could you help me understand?

Another point that was not clear to me, is that in remora eth-.c you treat vel_cmd as a float, then send it to a double new_vel and then to an int32_t jointFreqCmd, is this possible? take a double and send it to an int32 variable or I'm wrong, sorry but I'm studying to better understand rermora dds..

Hi, the threadFreq is passed in the stepgen constructor which is set in main.cpp configThreads() function.

Those conversions are possible with the compiler handling this with the appropriate loss of precision along the way. Maybe these should all be doubles or floats until the last conversion step to int32_t.

The dds accumulator is a little mystery with the logic copied from the standard linuxCNC stepgen component with the implementation split between linuxCNC and the controller board.

I modified the remora-eth.c to ignore and log any delta larger than 40 counts. I ran the controller through a simple program and collected several hundred error events. Occasionally such an event would cause the controller to become slow and unresponsive for 0.3-0.4 seconds followed by a reset. This usually results in a following error, turning off the machine. The rest of the time the errors were single jump events which were successfully ignored and logged by my modified remora-eth in the raspberry pi. 

263 out of 310 logged events involved a jump ~419 counts. 228 of those were near a stop or direction change. The rest occurred at low speeds. The other 47 jumps were generally 50-100 counts. They generally occurred while the axis was moving. 

I added a whole bunch printfs inside if statements and found that every once in a while frequencyCommand within the stepgen module has a value close to 2^24. It seems as though it is losing a byte somewhere. 

Interestingly: 2^24 Hz * frequencyScale (104.8576) = 1759218604 which is 419.43 x 2^22

This appears to be where the jumps of ~419 counts is coming from. On a direction change the high bytes go from all 0 to all f or back, if the highest byte is left out this results in a value of 2^24. I have also recorded values of ~2^16 suggesting 2 lost bytes. Without a direction change the issue does not seem to be as bad. Possibly the byte is retaining the old value, so if the values don't change too much it isn't as large of a jump if it jumps at all. This suggests that these errors are going on more frequently and going undetected until the value changes by a large enough to cause an issue. 

On the plus side this means the accumulator is working, its just getting faulted input for some reason. I wondered if this was coming from the copy from rxBuffer to rxData being interrupted. but the same check that catches frequencyCommand being out of range in stepgen does not detect an error when implemented immediately after the copy. I tried making multiple reads, but it consistently reads the wrong value. I confirmed that at startup the pointers are configured correctly.

I am not very familiar with the debugging tools or 32 bit microcontrollers in general. I have been reading about the debugger and how to get more data about the point of failure so hopefully I can drill down further to the root of the problem.