Remora - ethernet NVEM cnc board

More
04 May 2022 23:45 #242015 by royka
FYI today I've received the stm32f437 and soldered it on the board. Changed the clock speeds, recompiled. Exactly the same behavior.
The following user(s) said Thank You: spdbmp927

Please Log in or Create an account to join the conversation.

More
07 May 2022 07:41 - 07 May 2022 07:42 #242218 by scotta
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.

 
Attachments:
Last edit: 07 May 2022 07:42 by scotta.

Please Log in or Create an account to join the conversation.

More
07 May 2022 12:23 #242232 by royka
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

Please Log in or Create an account to join the conversation.

More
08 May 2022 01:30 #242282 by scotta
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.
Joint 1                                                                         
Count = 603943                                                                  
Acc(-3) = 0x1883D8FE51                                                       
Acc(-2) = 0x1883CBE91F                                                       
Delta   = -857394                                                                
Acc(-1) = 0x1883C4ADD5                                                       
Delta   = -473930                                                                
Acc(0)  = 0181B48E6A7                                                       
Delta   = -1759147674                                                            
                                                                                
Joint 1                                                                         
Count = 603945                                                                  
Acc(-3) = 0x1883CBE91F                                                       
Acc(-2) = 0x1883C4ADD5                                                       
Delta   = -473930                                                                
Acc(-1) = 0x181B69CFE1                                                       
Delta   = -1750785524                                                            
Acc(0)  = 0x181CE1AA9C                                                       
Delta   = 888540

 
Attachments:
The following user(s) said Thank You: tommylight, royka

Please Log in or Create an account to join the conversation.

More
09 May 2022 20:04 #242408 by royka
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.

Please Log in or Create an account to join the conversation.

More
10 May 2022 23:02 #242534 by andypugh

I thought that moving to a 64 bit accumulator would solve this, but maybe my implementation is not correct. 

A 64-bit accumulator really should avoid wrap. I calculated that 64 bits of accumulator on a 10000 rpm spindle and a 1024 pulse encoder was OK for many thousands of years of continuous running. 

So, I suspect that the problem is how you "promote" the input data to 64 bits. 

In the smart-serial driver, which supports variable length encoder buffers (they don't even need to be complete bytes) I took the easy option:

buffer64 += new_reg - old_reg
 

Please Log in or Create an account to join the conversation.

More
14 May 2022 21:01 #242978 by eng
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?

Please Log in or Create an account to join the conversation.

More
14 May 2022 23:13 #242985 by eng
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..

Please Log in or Create an account to join the conversation.

More
15 May 2022 00:50 #242993 by scotta
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.

Please Log in or Create an account to join the conversation.

More
17 May 2022 17:15 - 17 May 2022 19:09 #243180 by spdbmp927
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.
Last edit: 17 May 2022 19:09 by spdbmp927. Reason: Added more info

Please Log in or Create an account to join the conversation.

Time to create page: 0.236 seconds
Powered by Kunena Forum