I’ve just received my Maslow CNC kit from MakerMade.
Plugged in all the bits to do a test of the boards and motors and …
Something pretty similar to this thread: New setup - motors don't pass tests
Yes I have the power supply plugged into the Shield not the Arduino, and the power supply and USB leds are both glowing bright green.
Running the GC test - all the motors make a noise but fail to actually rotate. It’s like it’s a power supply problem (not quite enough).
I’ve tried going back to a previous version of firmware, but now the Arduino IDE doesn’t want to compile anything … (that probably belongs on a separate thread).
So … where should I start?
OK - I managed to get the Arduino IDE doing it’s thing, and then I verified the 1.25 version of the firmware and uploaded it.
Now all the drives pass their tests. So I’m guessing there’s something wrong with the latest firmware 
1 Like
There have been multiple issues with the 1.27 firmware so I am going to delete that release until we can come up with a more through testing process to make sure it isn’t going to cause trouble for anyone else. Sorry for the trouble!
Thanks - On the side of “extreme suggestions” - I stopped using c++ 17 years ago and never looked back. How’s about rewriting the whole thing in rust, or if that won’t work switching to netduino and write it in c#?
Porting everything in one go is peculiarly easier than you might think.
PS. .net core just runs on absolutely everything and makes it all so much simpler, plus better tooling (i.e. writing unit tests etc.)
The arrow is pointing toward migrating to grbl as the firmware (i.e., ditching the current firmware) running on a microcontroller, such as a esp32 or something. grbl is written in C++ and it’s pretty complicated and highly optimized. I’m not sure of the value of trying to rewrite it in another language… that would be pretty extreme 
3 Likes
I’d agree, rewriting code in one popular language that’s suited to the task to another one because it’s popular is a losing path, there will always be another popular programming language. C (nowadays c++) is highly portable and ported to almost everything, and while there’s low level code that has to be changed to move grbl to a new machine architecture (see Bart’s ESP32 port, among others) the bulk of the code just recompiles.
I could comment that c++ wouldn’t be my first choice for a real-time system with all that constructing and deconstructing going on (cpu cycles and memory ore precious on a 16MHz 328), but grbl does little or none of that so I won’t.
1 Like
I’d have to disagree. I’ve done this many times (I’ve been working commercially as a software developer, etc. for 35 years). Rewriting for the sake of rewriting is a silly choice. However porting to another language is an optimal way of paying down all of the accumulated technical debt and leaving yourself, and the code base, in a much better place. You gain significant insights into what the code actually does by porting to another language that you simply do not get by leaving it its present language.
Yup
For a very loooooong time the only practical alternative to assembler has been C or C++. That’s finally no longer the case, and that means that it is actually time to consider the choice of language. It needs to also be remembered that while great effort has been made to make C++ portable, that’s still only portable-ish, we normally have to solve that with mixing and matching compilers and headers for the right combination. Not a big drama, but still a fact of life.
So what would be your preferred choice?
Please let it not be python - it’s such a resource hog.
PS. Thanks for your comments - I’m new to this ‘space’ so it’s nice to be dropped into the deep end of what’s going on.
I thought all of the cool kids were doing Java these days…
Who else remembers Pascal? 
3 Likes
Back before Orakill bought Sun maybe 
Or Delphi
I did commercially code in 8086 Assembler many years ago. Yep, um, oh look at that! … (quietly walking away, hoping no one will notice)
1 Like
Seriously(ish) though
- .Net Framework (the MS Windoze specific one) d o n o t t o u c h - MS themselves are phasing this out.
- .Net Standard - the API definitions, this is what’s recommended for building libraries - target 1.3 and you have a good chance it’ll run on IOT stuff. Higher numbers mean more in the API spec, but corresponding less support on the tinier hardware.
- .Net Core - runs on OSX, Windoze, Linux, Android, whatever. The next big version of the .Net Framework will actually be .Net Core. If you hit v2.2 of this they made a massive change to C# that makes it a lot more performant (less memory, lots-o-faster)
Comparing numbers (I’ll find the link to the Open Source test suite some day):
If ‘C’ == 1, then C++ is about 1.03, Java is around 2 something (not bad, but I still hate it), older C# is about 4 (newer would be around 2), and Python is … well … 78
We’d love a volunteer to take it on 
1 Like
Well, gawk isn’t well suited for realtime, forth is likely near comatose, Snobol seems to be defunct, SQL isn’t appropriate, perl is on the outs.
You could probably rewrite grbl in LinuxCNC macros, but why? Fortran or BASIC? Guess I’d stick with C or a close variant since assembler (real programmers write binary machine code…) isn’t easy to port. Sure there’s all those buffer overflows, dangling pointers, or other fun stuff but efficient optimizers, code checkers, and in circuit emulators help lessen the pain and personally (I’m an old moose who grew up with dinosaurs) I’d do a simulation wrapper and beat it to death on a friendly platform with good testing tools.
Disclaimer, retired and minimal recent experience with oyster or snake derived languages, the last big project I undertook was several hundred lines of gawk to clean up a PDF table to text monstrosity. I do own a well thumbed copy of about the second printing of the original K&R that somebody doodled the C into a zero on.
Hey, me too, one of many. The engineer that started big, little, middle endian deserves to be lashed with their slide rule
I remember that joke:
“I write all my real routines in assembler, and all my comedy routines in FORTRAN”
1 Like
If you count that 7am Fortran (F IV with a mimeographed F II manual) class in high school, dang, it must be just past 50 for me, slightly longer if you count an IBM 407 self study book. A lot of that was real time, downlink telemetry, disk and communications controllers. Even an analog computer class, plus the usual eclectic collection if whatever needed to be done. Those first computers were powered by water wheels I think. Done assembler in lots of hardware, wrote and punched a short program in binary on a Friden Flexowriter that would boot off a paper tape reader (well, for bragging rights, just cleared memory) on an XDS 920, bit slice microcode (AMD 2900), EJBs (enterprise Java beans) and too much other stuff. Programming languages are just a tool and not as important as they sometimes seem. C works for me
And it’s really hard for a moose hooves to punch the keys on an 026 keypunch
1 Like
Wrote an IBM bisync handler for a Motorola 6809 in it for a 3270 emulator. The hardware was a big square circuit board that needed one corner shimmed up for the prototype to work. My at the time employee dumped it as not enough potential (and went bust a few years later), the department I was loaned to split off and turned it into hundreds of millions of dollars. I don’t think my code was part of that, though
Oh so true. Although “If the only tool you have is a hammer then everything looks like a nail.”
For this I’m not so sure.
It is true that arguing over little details tends to fall into the same trap of “premature optimization is the root of all evil”.
But I’ve also had the pleasure of mentoring and teaching to many different people. This has opened my eyes to how certain languages needlessly obscure things that are important, as in “if you use language ‘X’ you must remember to do ‘Y’ yourself”.
In our case, the firmware is in C because that’s what the arduino IDE supports
and so that’s what it was originally written in.
Since grbl is also in C, there’s no value in re-writing into a different
language, instead we want to make our code into a fork of grbl to reduce our
maintinance burden and gain the benefits of all their work
GroundControl and WebControl are written in Python because that’s what the
authors were most comfortable with and he who writes code trumps the hundreds of
people who want to tell them that they are doing it wrong 
I’ve used many languages over the years, some are more suited to some tasks than
others, but if you exclude those languages that are just not suited for the job,
arguing over which of the suitable languages to use just isn’t worth it.
And there’s a lot of value in the opensource world to using a common language.
Both C and Python are common, switching to Rust would significantly decrease the
number of potential contributers, so it’s just not worth the change.
David Lang
P.S. My first programming language was Fortran on a Univac mainframe, because
that’s what the games were written in that I wanted to cheat at while my dad was
doing his systems work. I then picked up basic and when I actually started
formal training, I did a lot of Turbo Pascal and Turbo Basic work, Cobol was
still a requirement when I finally got to college, but I had also picked up
assembly (Z80, 68000, 8086) along the way. I’ve been known to look over
someone’s shoulder and find bugs in their code when I hadn’t seen the language
before (much to that person’s annoyance at the time)
some people pick up human languages with seemingly trivial effort, I pick up
programming languages like that (at least, I pick them up well enough to make
software work and make changes to it, ‘professional’ programmers are horrified
at my code much of the time )
1 Like
and yes, to be pedantic, we are using C++ not C, but we are using C++ as a
mildly enhanced C, ignoring a lot of the power/complexity/resource hog features,
so saying things are written in C isn’t really very wrong