Feature/dm astepgen

[Geramy]

Fixed tftp upload and flashing, disabled dma, reset channels and deinitialized it. now flashing works and dma is no longer blocking flash.

[Geramy]

Issue #2

[Geramy]

Here is my HAL file https://pastebin.com/j6GH2pZT and here is my ini file https://pastebin.com/j6GH2pZT

I have stable movements up to a velocity of 1300. But the DMA is not actually outputting anything right now, not sure why, but the communication bit is working and the card is stable. Perhaps you have it disabled so it doesnt actually move, I havn't read that far yet just tried to get the tftp working again.

[Geramy]

Actually I guess its not stepping because it looks like the step pulse is to thin, 2us and not 2.5us based on my maximum allowed step pulse, I changed my local version frequency to 375,000 instead of 500,000 to test it out, even at 375,000 it seems the steps are very jagged.

[scottalford75]

Hi,

I need to add a step width feature, but this will limit the maximum frequency. There will be some jitter in the pulse stream as it is a DDS approximation of requested frequency. The underlying DMA frequency is the basis of the synthesised frequency. My testing is showing a good synthesised freq average.

Thanks for the work on the TFTP upload. I'll pull your work into the branch.

Not sure how you are getting higher than 40kHz as the LinuxCNC component will limit the frequency. I've modified remora-nv.c to up the frequency limit.

[Geramy]

I adjusted the DMA Frequency to about 120,000 while my base frequency in the ini and hal are 60,000 that seems to have made the movement 100% smooth and no joint errors. Yeah I was just explaining the step width to one of our electrical mechanical engineers and why it was being wonky. It seems that the base frequency and the DMA frequency at least to how its coded right now, need to be somewhat in sync. But I bet its something to do with my PID perhaps? anyways i'll post a video so you can see, its working way better, and I don't think i'm missing steps like I was with the software stepgen that you had, thats not your fault its just because thats how software step generators kind of are whereas DMA is way more stable.

[Geramy]

Oh and by the way the network latency is way better with the new DMA version, getting down to about 0.173ms that will be way better for the system i think overall. Just if we could get rid of some of the peak ping latencies, perhaps running the spindle through DMA also?

[Geramy]

So at F400 I can get the indicator to have an accuracy of 2.54mm exactly, but when I go up to F1000 my accuracy goes down, perhaps there is a setting that can reduce this error due to highspeed, typically we operate below 1200mm/m

[scottalford75]

Yeah, I was also pleasantly surprised how smooth the DMA stepgen was when I got it talking with LinuxCNC. Following error is much less. The network latency improvement would be due to the lack of the base thread ISR taking time.

[scottalford75]

So at F400 I can get the indicator to have an accuracy of 2.54mm exactly, but when I go up to F1000 my accuracy goes down, perhaps there is a setting that can reduce this error due to highspeed, typically we operate below 1200mm/m

pgain will be your friend. With higher speeds, the control loop will need to be tightened up.

[Geramy]

Have you experienced problems when moving up the base thread frequency causing tftpd and so on failing? Everytime I upload something above the frequency it likes, it shuts off the ethernet maybe because it doesnt have enough time to complete the ethernet protocol? I end up having to comment out load from json in the code and reupload a new json haha and then uncomment it and reflash.

[scottalford75]

There is a limit for a sensible base frequency and this is why Remora has been capped at 40 - 80khz. Just not enough time outside of the ISR's to get other work done.

DMA is now our key for higher step rates :-)

[Geramy]

Gotcha thats what I was thinking, by the way I love the work you been doing over at https://github.com/scottalford75/Remora-RP2040-W5500 I would love if we could get a all in one board like the EC500 but with your firmware over there, something a bit stronger where communications can be in its own thread and dma/servos can be in their own, it makes a lot more sense.

[Geramy]

By the way does base frequency effect the communications? I'm not sure I really understand how the frequency of communications work, if base frequency doesnt then i should lower the base frequency and leave it at 40,000 so it free's up the time for the ethernet card to handle communications, right?

[scottalford75]

With the DMA stepgen, in theory we could remove the base thread. It would only be needed for the software quadrature encoder module. Which I'm also hoping to convert to hardware.

LinuxCNC controls the communication (Ethernet), which is at the servo thread frequency.

[Geramy]

So there is still a bug in uploading via tftpd, I need to hunt it down, when base frequency is operating at 60,000 it seems to not want to upload a new configuration file it just halts and freezes the card, i'll see if i can hunt it down and submit another PR

[Geramy]

I bet we need to introduce some sort of wait inside the tftpd to make sure no dma transfers are still going on during the de-initialization of the DMA Mux.

[scottalford75]

Not sure if it would be of much benefit, but with the DMA stepgen we could move to an RTOS. Ethernet and servo updates in one task and DMA buffer prep in another.

I've not played with a RTOS but it would allow the removal of ISRs.

[Geramy]

yeah looks like i left out the DMAMUX part and just did edma, oops. now i can upload via tftp at 60,000 base frequency.

[Geramy]

you mean implementing an RTOS, or using something like FreeRTOS?

[scottalford75]

Yeah, using FreeRTOS in MCUXpresso.

[Geramy]

I'm wondering how much work that might be, but its a good idea. Perhaps all of the Remora versions can be FreeRTOS that way we can all share one code base but have hardware drivers. I would be down with that. Before we get to that can't we reimplement how ethernet and the servo thread work so it would be similar to FreeRTOS, or do you think that would be more effort than to just implement FreeRTOS?

[scottalford75]

The RT1052 is the only MCU which I've successfully got a DMA stepgen to work, due to the high clock speed. The original idea and code was on an STM32, but it was just not fast enough to do the stepgen calcs for 500khz. I think this will be a special case for the RT1052.

[Geramy]

Got it, not sure how but I reversed the direction by jogging at 1%..... Looks like 70,000 base frequency might not be the answer, going to drop to 65,000 and see if i can do the same thing haha.

[Geramy]

Looks like the card somewhere in the data packet in some cases is flipping direction, how do we get direction, its calculated right?

[scottalford75]

Direction is based on the sign of the frequency command.

Did you create a new config.txt file with the DMAstepgen info? Just realised I have not shared my config.txt file.

[Geramy]

I did create my own config file, I just read your code and then converted the Base and stepgen to DMA and DMAstepgen inside my config.

[Geramy]

Looks like PWM is going from 4v to 11v roughly I cant get it to properly work with my vfd either, got the probe working. Just need that last dang piece going.

[Geramy]

It looks like if I put the gain at 1 using the DAC mode, that gives me 100% 10v and down to 0% 0v, but thats also backwards for the VFD and it doesnt give me a scale so that i can set 24,000rpm if i put the dac gain with the scale correct for 10v I don't get anything I get like 0.02v to like 0.04v not sure if this is a bug?

[Geramy]

So I figured out if I put my VFD parameter 072 at 400.00 and 073 at 000.00 i get the correct 0 to 100%, but still i need to use a gain of 1. I cant seem to make a scale so that M3 s24000 means 100% and M3 s0 means 0%. Right now if I do M3 S200 its 100%

[scottalford75]

For the spindle, a SP of 0 to 100 will give 0 - 10V. You'll need to work you LinuxCNC HAL setup to give that 0 to 100 range.

[Geramy]

Okay, it works fine, something was wrong with my brain haha, I thought for some reason spindle override was related to M3 S command which it is after you feed in a command lol that was really dumb given im an engineer and all haha.........

[scottalford75]

Thanks for the bug fix, I remember now the issue and why the threads are also stopped. During the upload all executing code needs to be in RAM as XIP doesn't play well with Flash Write. The DMA callback would have been the issue.