You could set up GitHub to check out a commit, apply some changes to make a configuration, and at least build it (using platforming). Marlin does this for many many common configurations. Every time a PR is merged it has to compile with all these configurations. Our build kept breaking until we added a test for it. We still find runtime bugs, but they are much less common.
You couldn’t run automated tests on a build made for an Arduino in GitHub (afaik), but if you have a linux HAL, you can test the logic pieces (like pid and homing). These things are a pain to write. It isn’t fun to stop work on features to add tests. But if that is what is bothering you the most, it can pay off a lot.
I don’t know your background, but if you’re new to testing, my advice is to keep it pointed. Don’t test everything, just try to test the important stuff. When you fix a bug or add a feature, ideally, the tests don’t have to change.
Thanks.
I’m aware of the testing/building (I guess things like travis CI) but I’ve never learned how to implement this. But actually the major problem is not if the code compile or not. Is if when I fix a problem and it tests fine it didn’t changed some internal behavior in other part of the software.
One classical example of this is internal system flags or concurrency.
I’ve recently had a problem (fixed on this version) that was hard to diagnose. The firmware worked fine as far as I could tell. But then I tested a laser gcode that engraved the picture with a dithering technique instead of line scan. This produced an insane amount of short lines of interleaved G0 and G1 codes. At random points of the Gcode the step generation stopped. Report were being sent, the firmware was running… But it got completely stalled. No stack overflow errors, no infinite loops… Nothing. On all hardware… Except the virtual HAL for Windows.
I banged my head on the keyboard for 2 hole days.
My instinct said that this could only be a concurrency problem in the buffer that feeds the step generation ISR. And I was right. After small changes to the buffer and adding atomic blocks on part of code for the functions of this buffer all went smooth.
Long story short… Most problems are not if it compile and runs… Are if the behavior is what it should be.
But the Linux/Windows HAL would be a huge help. I actually used several Arduino emulators to test and debug homing motion (dual stepper axis homing too), spindle control etc…
The best I came across was simulIDE.
Do you recommend anything to virtually test hardware components? (even if it means developing an mcu HAL for that).
I would like to emulate how components interact with the firmware (stepper, switcher, servos, encoder, etc)
Thanks.
Yeah. Testing won’t catch everything. That sounds like a nasty little bug. I hope you got it.
I don’t have a good answer for you. I don’t have experience with a tool like that. Emulating a microcontroller sounds really hard, without making a bunch of other bugs. Simple stuff, like homing sequences in different input conditions are fine, but finding ISR bugs seems nearly impossible to me.
That’s what I thought the linux HAL was used for in Marlin. But I can’t put my finger on the test. It looks to me (at this hour) like they are only running platformio.
Someone must have solved this before. It would be very nice to be able to do tests like that.
Marlin uses GitHub actions (here is their config to get it to call make with some arguments and platformio set up). I hope you can kind of see they build up a list of targets (in the matrix) and run this workflow for any of the triggers. I’ve set it up on a few projects and it isn’t completely intuitive, but it is pretty nice and integrated in the PR and release system.
I believe I did…or at least I hope … The gcode tests I’ve run are executing just fine.
Yes debugging in these architectures can be somewhat tricky. For AVR I used mostly emulators like simavr and simulavr that expose a gdb server, but it’s not the same has running code in the Arduino. These emulators tend to explode from time to time. For ARM Cortex my biggest ally was an extra STM32 bluepill I’ve programmed to be a CMSIS-DAP and Openocd running the gdb server. I then use VSCode to debug (just plain VSCode without platformIO). An extra trick I sometimes use is to add specific code (for example an if clause with some useless code) to do a break point with a specific value on a variable. Memory access breakpoints I rarely use but they have proven useful to check if pointers go beyond expected.
Someone told me about Github Actions. I’ve peeked but didn’t dug deep in the matter. I’ll have to take a closer look. Thanks.
Since then I released 3 updates that addressed most if not all parsing and motion issues. I use these test files to run every patch/commit I do before merging with at least 2 different MCU. Everything seems to be running really smooth and precisely.
Encoder module is running and as far as I could test is working fine. It’s allows configuration of bi-directional encoder or a simple counter encoder (that can be used to measure tool RPM).
As for PID module, although implemented it’s still in it’s early stages. I need to build a test setup for that.
I’m working on improving the Windows virtual HAL MCU adding a visual app so I can interact with the virtual IO (inputs, outputs, PWM, Analong inputs).
You can see the DOS window that is µCNC c executable running the virtual MCU HAL in windows.
Bellow that is a C# GUI that displays the status of the output pins and allows me to interact with the input pins and analog inputs. Nothing to fancy but at least is more practical to interact then a txt file like I had before.
On the left is OpenCNCPilot that I use has a Grbl interface app. It’s connected via a virtual serial COM port but both OpenCNCPilot and the virtual HAL also support connection via socket (it’s slower).
As they say… The proof is in the pudding… After laser engraving an image I saw some artifacts and I instantly knew where the problem was.
So after a quick change in the code… Voilá.
This is the outcome on a piece of scrap mdf of the latest version I released today.
STM32F4 is now partially implemented. It lacks EEPROM emulation and analog pins were not tested. Despite that I believe is now usable and has been merged in the main branch for the next major version release. For now a configuration file for blackpill boards is available and is somewhat similar to Grbl’s bluepill project.
Modification to the stepper interpolator were also added to allow a S-shape acceleration profile.
Due to thread discussion about use a delta machine as a surface scanner
this new release will also include dedicated servo control signal type pins. It will also come with an early (in tests) delta kinematics HAL and further developments of modules that are (PID and Encoder/counter) or will be integrated (special types of probes like bltouch, gcode extensions, etc…) in the near future.
Pre release version 1.4.0-alpha is out with the usual prebuild binaries for UNO, MZero, Bluepill and now Blackpill boards.
Main features now integrated are:
added optional S-Curve acceleration (linear acceleration is default). Also legacy stepper generation (prior to v1.4) is available
added new SERVO pin type that outputs a 50Hz type PWM(Ppm) . Up to 6 SERVO pins can be configured. To support these pins M10 code (set servo pin value) was added to core parser (there is also an optional parser extension to support a partial implementation of Marlin’s M42 that can be used to set any output pin on µCNC)
partial implementation supporting STM32F4 core. Lacks Flash EEPROM and analog pin reading is untested.
experimental delta kinematics added to HAL (partially tested)
resigned module system to accelerate the development of extension modules inspired on C# event/delegate/listener mechanism. This allows to add hook calls inside the core code that are then intercepted by the extension modules.
added initial implementation of bltouch module (untested)
Although still in a early development phase, I have high expectations on the new module system to open up some doors to introduce quick developing opportunities.
The first one that actually pop’s up in my mind is simply add software implemented interface (for example serial COM) PORT and a module on top of that one to enable trinamic driver support.
Just released version 1.4.0-beta2. Besides several fixes added by the previous beta version this now adds:
Basic Trinamic driver support. I’ve only tested with TMC2208 because these are the only ones I have with me, but I think other UART Trinamic drivers should work as well. The library also supports SPI trinamic drivers but I have not tested those.
I’ve also updated the boardmap for RAMPS and RAMBO. For this last one I also added a digipot module to set the stepper motors current and a digipin module to set the MSTEP pins. I don’t have a RAMBO board so testing was quite limited.
Also thanks to @bastardazzo and @jeffeb3 I’ve done some fixes in the kinematic for linear delta machines (this is still being developed).
EDIT: Almost forgot. Also a subset G8x canned cycles are also supported (enabled via config file)
The new module system as really helped me speedup adding new features to this project.
Probably the next module I’ll be adding is going to be a graphic display to this…I have too many things rolling at the same time.
Version 1.4.0 is out. Resuming all things added since prior versions 1.3.x:
added optional S-Curve acceleration.
added new SERVO pin type that outputs a 50Hz type PWM(Ppm) . Up to 6 SERVO pins can be configured. To support these pins M10 code (set servo pin value) was added to core parser (there is also an optional parser extension to support a partial implementation of Marlin’s M42 that can be used to set any output pin on µCNC)
increased number of generic IO’s in the internal firmware mapping.
resigned module system to accelerate the development of extension modules inspired on C# event/delegate/listener mechanism. This allows to add hook calls inside the core code that are then intercepted by the extension modules.
added initial implementation of bltouch module (untested)
Basic Trinamic driver support. I’ve only tested with TMC2208 because these are the only ones I have with me, but I think other UART Trinamic drivers should work as well. The library also supports SPI trinamic drivers but I have not tested those.
I’ve also updated the boardmap for RAMPS and RAMBO. For this last one I also added a digipot module to set the stepper motors current and a digipin module to set the MSTEP pins. I don’t have a RAMBO board so testing was quite limited.
1.Integrated a subset G8x canned cycles are also supported (enabled via config file)
Also thanks to @bastardazzo and @jeffeb3 for the help on the Linear Delta Kinematics HAL development.
And also a thanks to @dwburger for the tests on the Inventables X-Controller board now added to the HAL.
Several crucial bug fixes and optimizations to improve the the overall performance (quite visible in the gcode stress tests).
Hi @Paciente8159 - I’ve just loaded µCNC onto my MKS GEN L board and giving it a go. I’m super excited about this project. One thing I’d love is a command like Marlin’s M119 which can help explain which end-stops, etc, are triggered.
Thanks for all the great code - I’ll be familiarising myself with the codebase to see how I can help.
Hi there. Thanks. The status message has that.
Just send a ? And the status message Will contain a Pn: followed by the input if any is active.
For example if the X endstop is triggered it Will have a Pn:X on the message.
Hi there. Sorry for the late reply.
For now only a minimal setup is available on µCNC (microstepping, current and stealthchop threshold) and testing was only performed in Tmc2208.
Sensorless homing is a feature that I intend to build in too in a near future.
The uno is short in pins and program memory but maybe do-able. What would be your application/setup be out of curiosity?
Thanks for reply…
Well, I want to make CNC, and sensorless homing would be really cool feature…
I have TMC2209, but maybe I will change them for TMC2160…they are bigger, stronger, etc…
Arduino uno don’t support lots of features TMC drivers has…if that is only because of software, and you know how to do it…it will really be usefull…
Sensorless homing is not a great option for CNC. It is not all that accurate. Even if ultimate accuracy is not your goal, tool changes could show it the most because of compounding errors.
… The gcode tests I’ve run are executing just fine.
) can get better but thats a matter of finding the right contrast and brightness ratio in laser grbl.
