Nice to see the Revolve control board coming alive. I have two observations that I’ve discovered while working with this: 1) Rapid configuration and 2) Higher/more flexible bandwith comms between the firmware and the control software.
It’s been a lot more work than anticipated with configuration of the TMC2130 drivers. They have a lot of options for configuration, but really these are things it would be great to experiment with in a quick manner, sort throw-something-at-the-wall-and-see-what-sticks experimentation, like with rapid prototyping in general. Redeem now has two ways of testing things out and configuring: G-codes and a config file. The former is good for experimentation, since it allows a workflow similar to how one works in a shell. But it’s a pain remembering G-codes and even with built in documentation it’s not a great tool. The other option is editing the config file, but this requires a restart or Redeem which takes several seconds. OctoPrint has an interface for making custom control. The ideal scenario would be to have a get and set interface in OctoPrint, now one can only set values, they can not be read back. Are there other options? A rest interface and a separate web interface?
Which brings me to observation numero dos: I’d like to get more data from the firmware. I’d like to push the boards power consumption, the load on the steppers (for stall detection calibration), quad encoder data for filament flow monitoring and other relevant stepper stuff. I’m sure there’s more as well. I guess this can be piggybacked on M105, but I’m thinking it’s somewhat painful and taxing extracting the data if the rate is increased to sun second requests. Most of this is actually OctoPrint related, but that’s the control software I know the best.
So before mapping out the roadmap for Redeem at least, I thought I’d check and see if there are any serious initiatives tapping into these questions. @foosel@Justin_Nesselrotte you might be interested in this discussion : )
Originally shared by Elias Bakken
Finally got the new 3D-printer control board running today! #revolve
@_Spice Well if that is your dream, you should dream bigger:) Redeem uses socat to set up a virtual tty, so no USB involved. That is unless you want to use a control software on your computer, but even then you can use Ethernet/wifi, I think Pronterface at least has support for that.
@Elias_Bakken My dream is more to have USB communication for printer control and tethered printing, much like how our current Serial system works, but using raw USB instead of Serial. This keeps the overhead for a user interface off the board itself so you don’t have to worry about the board handling graphical rendering or having to be a webserver, and can instead offset that to a raspberry pi or other device. The reason I’m unsatisfied with with Serial is that, with the highest baudrate being 115000 bytes per second, it’s abysmal to do any sort of tethered printing. Compare that to USB 3.1’s potential 10gbps, it’s obvious we’re using the wrong standard (especially if we’re using 32 bit ARM processors instead of 8-bit AVR’s).
Your idea is interesting and a step in the right direction, but I just don’t care for tether over network, as you’re bottlecapped by your network speed, and if you wanted to print without a network, say, at a convention where access to a wireless network in the building gives you limited abilities to set a static IP and even worse, network congestion could slow data and cause outages, you’re out of luck or would have to bring additional equipment with you.
In conclusion, I guess I’ll have to continue my research on developing my own board that uses such tethering instead. Sadly I don’t have the time to come up with anything meaningful in the near future lol
Your’s is still a nice board and would be a perfect choice currently.
The baud rate on a CDC does not limit the speed when there’s no physical TTL/serial link involved in the chain. Now granted many of the standard controller boards use one AVR chip for the firmware and one as a USB to serial converter which does not make sense either for cost reduction or speed, only for compatibility with Arduino. But disregarding the dumb design of two expensive micro controllers doing the job of a single sub $1 STM32, the bigger bottleneck lies in the g-code standard requiring an answer for each line sent. There is no need for higher bandwidth over the USB cable, the 480Mbps of USB 2.0 is plenty and much more cost efficient. Really what we need is a look at the gcode “standard”, but it seems nobody wants to touch that stuff, hehe:)
+Elias Bakken very true, but I think nobody wants to touch gcode because it’s become too established, much like how flash is still in use on a number of websites (though, we have newer, better standards so that may not be a good comparison). As for the data speeds, you are correct. We could get away with even USB 1.0. I just want an excuse to use USB-C instead of micro or mini lol
So from what I remember, @foosel is working on OctoPrint 1.4 to have a completely modular comm layer - we could bypass the serial comm between OctoPrint and redeem completely and write a custom plugin that would give you a complete bi-directional API in that case. Sure it’s not ready yet, but then, neither is the Revolve ready for mass production just yet either, right?
Also, @_Spice There’s been so much work done in Redeem’s path planner optimization that really the current bottleneck really is serial communication. We’ve got an attempted bypass of that in the latest develop branch where we emulate SD card behavior from Marlin, so OctoPrint passes Redeem a file handle, and Redeem reads ahead in the file. OctoPrint then only has the M105 and M27 messages over the comm line every second or so. Everyone who’s had it working has found it fantastic, and it really shows off the firmware+board capabilities of a 1GHz ARM CPU doing move computations and offloading the real-time management to dedicated chips.
What Firmware are you using?
I will suggest you get Marlin 2.0 HAL setup for your board.
What MCU are you using?
STM32 based on your comments?
The control board STEVAL 3DP001V1 HAL is currently under development, which uses the STM32 Chipset… Maybe a good opportunity to get your board supported as well…?
The firmware is redeem, since it shares so much of the architecture with the replicape and beaglebone stack.
I doubt Marlin hal would work since here the moves are coordinated by the PRU chips and not the stm32. The idea is to decouple the computation from the coordination of moves here, something I doubt Marlin can do.
Redeem runs on top of a standard (i.e non Real Time) Linux distribution with a few extra packages ready for the PRU communication etc that we’re calling Kamikaze or umikaze, depending if you want stable or testing versions.
@Panayiotis_Savva Marlin is a big mess of ifdefs designed for an expensive 8bit AVR without an FPU.
Redeem uses Python for high level stuff (comms, probing, setup) a small core with C++ for the path planner. The path planner relies on the NEON FPU in the AM3358 for faster and better calculations, especially for deltas. Paths are pre-planned and given to a PRU which handles the real-time aspect of this, since most of Redeem runs on a vanilla Linux kernel.
So thanks for the suggestion, but unless Marlin does something radical to clean up its code, I’d rather not touch it. A HAL sounds like a great step in the right direction, but I imagine it will be a long time until it’s ready and Redeem works out of the box with this board:)
Please do have a look at version 2.x, as a lot has been rewritten and refactored. HAL has been implemented for some boards. The initial concentration was on the Re-Arm. Some nice features such as Linear Advanced, Unified Bed Leveling, and Babystepping…
The reason i suggested it is because of the TMC2130 (amongst other) support using SPI.
@Panayiotis_Savva Redeem was built for the Replicape and implements TMC 2100 support already. The change from 2100 to 2130 is peanuts compared to swapping to Marlin 2.x… Specifically because Redeem lets you run a proper linux backend with on-board octoprint or repetier server if you’re so inclined. The whole linux stack being available makes life so much simpler to handle the printer through networking alone that I’d hesitate to migrate away from that.
