-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using Remora for controlling analog servo drivers? #70
Comments
you could probably do it now with an stm32f4 without anything special in firmware, if you dont need the analog input Personally, I do need analog/pwm input but I dont know how to do it yet. |
Oh really? That's interesting. How many encoders could be read reliably at say 50kHz, do you think? For this application I really only need two plus a low speed for MPG. But for a more extendable board it would be nice to read at least 4 axes plus MPG. That also lines up with a decent looking 4ch DAC I found. Don't need analog input. |
Does the firmware now have a way to talk to a DAC over SPI? Or could the RPi talk to the DAC directly? |
you could have rpi talk to the dad but I dont think that would be fast enough. I dont know how to do a DAC, but for spindles that use 0-10v, we are using PWM to analog via an opamp like on the regular DB25 breakout boards |
That would certainly be cheaper and a more direct. Only question is
whether the time response would be fast enough. 1kHz DAC update rate
should be fast enough for most systems. The PWM frequency would need to be
a fair bit higher to reduce filtering delay. What is typical for spindle
PWM frequency?
…On Wed, Nov 20, 2024, 11:06 cakeslob ***@***.***> wrote:
you could have rpi talk to the dad but I dont think that would be fast
enough. I dont know how to do a DAC, but for spindles that use 0-10v, we
are using PWM to analog via an opamp like on the regular DB25 breakout
boards
—
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6UZAAHDMWPPZNIBNPQPMD2BS6SPAVCNFSM6AAAAABSA4PFMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBZGEZTGMJWG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hmm Im not sure, here is what the manual says for specs https://remora-docs.readthedocs.io/en/latest/firmware/Setup-Config-File.html#pwm |
Ahh, ok. So the maximum PWM frequency is 5kHz. On the surface that seems low but maybe it really isn't. Ultimately what this is controlling is motor torque. Heavier filtering (to remove the 5kHz) just means the motor torque will take longer to build, thereby reducing response time. But this may be insignificant compared to the mechanical response time of the system overall. I've been trolling through the code to try and figure out what is actually limiting the PWM frequency. Is it related to the hardware timers? Anyway, I think I just need to try it out. Also, the software encoders appear to be limited to 30kHz. Is that referring to the full pulse frequency (full quadrature cycle) or is it the individual pulse frequency (1/4 quadrature cycle)? Either way it should be fast enough for my particular machine. But for higher speed encoders likely not. Is it possible to have more than one QEI encoder? From the code it looks like there can be only one. |
For the PWM, im not sure the limiting factor, or if hardware PWM can be faster than software for the software, I think is tied to some division of the basethread if im not msitaken, so running a faster basethread on might give you more. I assume its refering to full quad, but I do not know. For STM32 boards, it is possible to use more than 1 QEI encoder, as the STM32 has at least 4 hardware encoder channels, but the firmware needs modifactions to make that happen |
Cool, that all makes sense. So I picked up a nucleo board to mess with (446RE) and found the specific Remora repository for it. After getting LCNC setup on a Pi4b and flashing the firmware for the static setup (no SD), it seems like LCNC and Remora are communicating but it doesn't appear that any of the inputs or outputs are responding. This is beyond the scope of the original question here, so I'm wondering if it would be better to start a thread over on the LCNC forum or continue here? Either way, thanks for all the assistance so far! |
If you wanna do it on the forum, use the existing Remora-SPI thread because it gets hard to keep track. Otherwise, if Scott doesnt mind, Id rather just do it here because it gives me little pings when theres a notification. It is Remora related, and the only reason I have not merged it into the main Remora, is because theres some code changes I need to make but dont know how. First and easiest way to see whats up, is plug the Nucleo into the usb port, and open up a serial thing, using cutecom minicom, or even the mbed studio. But if it was the nucleo static you wanted, I think you cloned the wrong repo. I saw you cloned the SD card repo, so I spent time today updating it. |
Ok, I'll keep going here unless told otherwise. :-) I cloned the SD repo first but it seemed like the nucleo wasn't reading the SD, so I switched over to the static repo to simplify for now. Cutecom is able to connect and show status messages when the nucleo is plugged in. It's not giving any error messages and it stops at the idle state, so that's good. If I start LCNC I can get it to the run state by hitting the estop button and the 'on' button. This is where if I try to toggle any inputs (pull to ground) or check outputs there is no response. I don't have any shield for now so I'm just trying to verify that the IOs work. Once they work I can start breadboarding the needed interfacing parts and work on replacing the step outputs with PWM channels. |
The SD connection, probably requires some hardware somewhere or something like that. I found the adapters to be hit or miss, some work no problem, some work if I jiggle the wires. There probably needs to be a resistor or something somewhere, or something 5v/3.3v. The SD version is your best course of action thought, not all modules are supported in the static config. To test, I usually use the onboard peripherals first, the userbutton is connected to remora.input.07 so you can view that in halshow. I just have microswitches connected to io/gnd and it works without anything special. The LED is connected to the DIR port of the A axis it looks like, but I dont think I made a sample config with J3. I put a PWM on PC_6 and theres a few encoders also |
The SD reader is supposed to work with 3V or 5V. But I didn't try swapping out readers and cards, which I might do next. Ultimately when I get a real board spun up for this I intend to have a card reader on it, because having to recompile to change configuration is annoying. That should be more reliable because it will have a shorter path and not have to go through questionable quality jumper wires. But for the moment I just need to get it talking to outside hardware. I'll try the button later and also see if the SD firmware spits anything out on the serial port. The only thing I was getting with the SD firmware was a blinking LED on the nucleo. It was blinking in a pattern though (4 short, 1 long) which made me think it was intentional, but a google search didn't yield any information of that being a thing. |
Making progress... The user button didn't do anything in halshow with nucleo_static so I switched back to nucleo_sd. After fetching the latest changes the nucleo will now read the SD and setup the modules. On the LCNC side the button still does nothing in halshow, and now it won't even come out of estop. It says the external estop is set, could not change state. Nucleo_static would at least allow estop and power on from the GUI. But neither firmware seems to have any effect on IO at all. So probably there's something wrong on the LCNC side. |
Edit, If you are using the SD card firmware, did you load a config on the SD card? Lets just start from the beginning
Edit, If you are using the SD card firmware, did you load a config on the SD card? I added the button to the SD config |
With the SD card, yes I did have the config file on it. According to the messages in Cutecom it was reading the card and setting everything up. But for some reason LCNC wasn't really talking to Remora somehow. Anyway, I went back to the static version per your directions above and now the inputs are responding in showhal. One thing I'm curious about though... I can toggle the estop button from the gui, but when I toggle the actual pin it doesn't change anything in the gui. I would expect it to go into estop mode but it doesn't. It shows the pin toggling in showhal, but nothing else as far as I can see. One thing I'm noticing is that this thing is really sensitive to noise so I need to get it on the bench with a static mat and proper power supply. With the SPI reader in the system there might just be too much noise due to the extra wires. But that's a tomorrow problem. |
Ill test out the SD one again once I set something up and let you know. Dont know what to tell you about the estop pin though The noise....Im glad you mentioned it, because yes, it seems waaaay to sensitive for some reason. I have other non nucleo dev boards, and they seem to have more immunity to noise than these nucleos do. One thing that makes a big difference, short cables, and keeping them in the ribbon, with grounds. Im using regular ol dupont cables, and when they are individual, it makes it much worse, than if still part of a ribbon. If you have any ideas for how to make this better, I am all ears...maybe some resistors...or something |
I have no prior experience with the nucleo, but I have used SPI before. It can definitely be fussy, especially at higher speeds. Best is to not go through cabling at all. If cabling is necessary keep it as short as possible. Ribbon cables with grounds between each conductor will help. Sometimes resistor termination helps. And keep the SPI speed as low as feasible. Another potential problem I see with the nucleo is that all those pins sticking out are basically little antennas. All unused input pins should be pulled up (or down) either internally or externally. It's also possible the power supply needs extra decoupling capacitors too. I'm not an EE though so I'm sort of guessing here. |
I know there are no boards that do this currently, but I'm wondering if there's any reason Remora couldn't be used to run a servo controller if a suitable board was built? Specifically my use case is an old Bridgeport EZTrak that has an archaic PC based controller running analog servo drives. Everything works now, but I've had to replace several parts of the PC over the years and it's getting more and more painful when it goes down. The existing control is also terribly primitive as far as programming. It would be great to replace the PC and CRT with a nice RPi and LCD display and keep using the existing motors and drivers, since they work fine. The motors have been fitted with digital encoders so no need to read analog resolvers.
My thought was that an RP2040 could be used to read at least 2 encoders and also run a few DACs for analog output. Add an op-amp to scale the output to +/-10V and a few Optos for general IO. It sounds doable in terms of hardware but I have no idea if Remora would support such a thing.
Any thoughts on this? (Other than "just go buy a Mesa board" Lol)
The text was updated successfully, but these errors were encountered: