Remora - ethernet NVEM / EC300 / EC500 cnc board

More
4 years 5 months ago #242232 by royka
Replied by royka on topic Remora - ethernet NVEM / EC300 / EC500 cnc board
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
4 years 5 months ago #242282 by scotta
Replied by scotta on topic Remora - ethernet NVEM / EC300 / EC500 cnc board
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.
Code:
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

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

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

More
4 years 5 months ago #242408 by royka
Replied by royka on topic Remora - ethernet NVEM / EC300 / EC500 cnc board
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
4 years 5 months ago #242534 by andypugh
Replied by andypugh on topic Remora - ethernet NVEM / EC300 / EC500 cnc board

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
4 years 5 months ago #242978 by eng
Replied by eng on topic Remora - ethernet NVEM / EC300 / EC500 cnc board
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
4 years 5 months ago #242985 by eng
Replied by eng on topic Remora - ethernet NVEM / EC300 / EC500 cnc board
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.

Time to create page: 0.234 seconds
Powered by Kunena Forum