Firmware for UMO+ containing a fix for the M42 command

[etix 4]

Few days ago I bought a 24v LED strip to add to my Ultimaker Original+ but after setting everything up on port J15 I wasn't able to control it. It seemed the firmware was crashing right after sending the M42 command.

In fact it was a firmware bug, the issue has been fixed for the UM2 but not for the UMO+ yet so I built my own version that I made available on Github.

This is the result:

The intensity of the light can be controlled by PWM using the the M42 S[0-255] command. 0 being lit off and 255 being maximum brightness.

To flash, just get the proper firmware in 115200 or 250000 baud and single or dual extruder and use Cura to install the custom firmware.

Hope it helps

Edited November 26, 2015 by Guest

[jvcraen 0]

Hello there,

My UMO+ shows exactely the same problem and I hope that you have the solution to it.

What was the bug with the M42 command and what did you have to change in order to get rid of it?

Kind regards,

jvcraen.

[amedee 349]

This is 'funny' because I never experienced that issue myself although I always use the LEDs...

But it is indeed a bug, for the ones using my builder that fix has been committed a couple of weeks a ago as well in my branch...

[jvcraen 0]

Hoy,

We now run the modified firmware as proposed by ETIX and our printer transformed in an intense light source. The 24V leds can do their job at last.

I am new in the world of 3D printing, which means that I am haunted by many unanswered questions.

Suppose you receive an UMO+ as a New Years present from a friend. How can you know which firmware has been uploaded into the Arduino memory? On the display of our printer eg. you will get the cryptic answer: Control -> firmware version -> DEV. 250000_single.

When I look at the comments, replies, hints... on the internet it seems important to get a bit more information than that. Because depending on the firmware version, origin, flavour ... the printer is loaded with, it is going to respond differently to the led problem. Version12.9 seems to work version 12.14 not, modified UMOP-250000.hex is OK, the UMOP-250000.hex which came with our Cura version (2.3.0) is not and so on. Is there a satisfying answer to our question?

Any comments?

And by the way a very Happy New Year to you all.

[amedee 349]

Ultimaker's Marlin for UMO has not been modified since ages, but each time there is a new Cura it is recompiled from sources, so you get a new version number for the same software...

The issue we are talking about in this thread is a buffer overrun, so depending on how it is compiled you may or may not have issues which explains why some versions runs and other don't...

To be more accurate, the version also corresponds to tags in the GitHub source tree, so you can go back to sources and check the differences. But as you will see, last 2 years tags are pointing to the same code.

(Shameless plug: if you like playing with the LEDs, my firmware branch allows you to set brightness from the controller and save it in NVRAM so you get light at power on)

[jvcraen 0]

Thx Amedee,

your last remark seems very interesting. I will look into it tomorrow or the day after.