Dancing through an upgrade has left me with nothing but ALARM:3

Dear fellow Maslow tamers,

Hello from the bottom of the world!

After a brief affair with a CNC laser cutting machine leading to a desire to then build my own CNC plasma cutting table, I now find myself back in the arms of my faithful old Maslow that hasn’t seen much action in 18 months since I took the router off her to replace it with a pencil (when I wanted to draw something big :slight_smile:

Rather than sticking to one thing at a time I decided it would be a good idea to finish that pencil mount at the same time as getting the machine up and running again with a new dedicated Raspberry Pi on which I could run MakerVerse and catch up with the cool kids I read about here in the forums.

Of course that meant a firmware update for the Arduino too. I run an old V1 MakerMade shield on a 2560 Mega, and I had found a hex file for 51.29 which I loaded onto it and used to successfully go through the calibration process, achieving 2mm accuracy on 2 passes! :slight_smile:

I did have to change the ‘z axis Kp Pos’ parameter value to 1300 to get the Z axis working (it would hum but not rotate with the default setting of zero), but after that I was able to draw myself a very accurate 100mm square with the jogging controls.

I then decided I wanted to draw a spiral from the centre of the board outwards and so I moved the sled to the centre, created an SVG in Inkscape and then used cough cough MakerCAM to generate a quick NC file and uploaded it for a ‘cut’.

That’s when it all went to ^H^H^H^H downhill! The sled only moved a very small amount (<5mm) and I got ALARM:3.

Now let’s cut a very long story down to just a long story and say that in the troubleshooting that followed that, I have so far been almost completely unable to move the sled away from the centre position.

In amongst the various attempts I’ve made, I’ve tried with firmware versions 51.29, 1.28 and 51.28. The former 2 I compiled from source, the latter I picked up from a repository I’ll link below [1].

All 3 of them give the same ‘ALARM:3’ behaviour as soon as I try to move the sled, either with manual GCode commands, jogger control or using the calibration screen functions.

I have loaded the Arduino EEPROM clear sketch and cleared the EEPROM in case there was some stuck setting.

From what I can gather ALARM:3 is to do with sled position not being ‘detected’ (?) as being in the right place. I’ve changed the ‘position error alarm’ distance from 2mm to 20mm but it makes no difference - the sled definitely doesn’t move 20mm. It doesn’t even move 2mm.

I currently have version 51.29 from the pre-compiled hex at [1] because I’ve been unable to find a repository for the source for 51.28 (if anyone knows where that is hosted I’d love to know).

My full list of settings are shown in the attached screenshot.

I could be convinced that this is a bizare spontaneous hardware problem with an encoder or motor or controller board, EXCEPT that I found a posting mentioning a ‘b04’ GCode command which tests the motors and encoders and when I run that each motor moves perfectly in each direction and all tests pass! She’s alive underneath Jim!

Does anyone know if there is any documentation about the motor-test routine I could read? I guess I could go read the source code for it - maybe I’ll do that. I’d be keen to have the tests operate over a longer distance just to see those motors moving again! :slight_smile:

Anyway, this is how it goes with the Maslow. I’m not complaining about needing it for work - this is a hobby. I’m already 2 weeks into the ‘upgrade’, and I’m sure I’ll get it figured out eventually. I just need some steering…

MacgeekNZ

[1] Releases · WebControlCNC/Firmware · GitHub

I’ll be up front that I don’t know anything about “ALARM:3” but if what you have posted is true, have you tried resetting the chains? I know you moved it to center and that worked before, but if it is not detecting the sled position, it is basically saying it doesn’t know where the sled is with regards to the machine. I want to sat a reset of the chains would tell it where it is and might fix this error.

2 Likes

A couple things:

  1. when you flash the firmware from 51.28 to 51.29, you probably should wipe the eeprom (based on your settings, you are using triangular calibration, but with holey firmware, you should be using holey or in makerverse speak, precision calibration).

  2. simply reflashing will not fix it, you have to step through the precision calibration in makerverse (what version makerverse are you using?) If you have already done this, then I’m at a loss at the moment. In the makerverse software, if you check the beta box, you can get 1.1.3 or 5 I believe and that may not fix it, but the newer version is better. There should be a orange/yellow “set home” or “reset chains” button upper right that you will need to press when the sled is in the middle (depending on which version you have). also you may need to turn off the softlimits.

all of these suggestions have very specific commands and I’m crunched for time, so I have not included them. I’ll hopefully be able to edit later and add them in, but I’ve posted on how to do this in a few other threads, so search for soft limits and reset flash.

2 Likes

I also don’t know anything about ALARM:3, I believe that it is specific to Makerverse, it might be worth asking on their facebook page too because you might find a faster answer there.

1 Like

Gentlemen, you each have, as usual, provided very useful answers and I will now follow them up and report back my findings in due course. Thank you for your attention and responses!

@bar - I’m only on Makerverse because I thought that was supposed to be the bees knees these days. I’ve been a Ground Control boy on macOS and WebControl on Linux! I’m open to anything, but I thought I’d seen a post from zaneclaes saying he’d got rid of his machine and wasn’t developing WebControl any further and MV was the best bet for the future. Maybe I’ve got the wrong end of the stick there, so if the project’s got a new leader or is so damn stable you think it’ll last forever anyway then I’m all for zeroing my SD card and starting again! :slight_smile:

I know @Orob has been working on some updates for WebControl, so that is still alive. As far as GroundControl, @EastBaySource has been working on keeping that updated and refreshed. I believe you can still uses all 3 if you want. Makerverse is what @MakerMadeCNC has developed for their updated M2 Machine with the Arduino Due controller. They have made it compatible with the Mega version, but with that, you still have the option of all 3 control software choices. I am still running WebControl, and I have had no issues (other than the self induced kind).

I did some searching in the makermadecnc/makerverse github repo and found this.

The alarm:3 in makerverse is the infamous “sled not keeping up” error.

1 Like

Rick & Rob, thanks again guys for your helpful tips - they pointed me in the right direction and I’ve had another big learning experience on my Maslow journey :slight_smile:

I can report that I am up and operational again now thanks to you both. Along the way I discovered a few things that were new to me which I’ll try to summarise for the benefit of future readers.

I think there were a few different things are play, including my lazyness at not repeating the calibration cycle between different software and firmware attempts, and also potentially some dodgy gcode I generated that upsets either MV or the firmware (not sure which - see more below).

I had developed a desire to build the firmware from source due to in the past having to select the shield type by uncommenting a define line. I have now discovered that this is not necessary in newer firmware releases because the software checks the state of some indicator pins at boot and determines the shield type from that.

I was worried that if I ran someone else’s hex they uploaded then it might not be for the correct shield type! So I was looking for the source for 51.28 and I found the repo at Release v1.26 · WebControlCNC/Firmware · GitHub but the source ZIP archive there doesn’t seem to contain version 51.28 - after compiling it the Arduino reports version 1.28 not 51.28. The version appears to come from the file cnc_ctrl_v1/Maslow.h and it’s set at 1.28 in both the ZIP and TGZ source archives.

So the binary that you end up compiling from that source differs to the binary included in the ‘holey-51.28.hex’ file in the same repo and if you use the one compiled from source, MV refuses to connect to it because it’s not version >=51.28.

Anyway, eventually I found the part of the source that let me understand that I don’t need to set the define any more and then I thought OK maybe I can just use this 51.28 hex after all no worries with my shield. So I wiped the EEPROM and loaded the hex.

There was another problem with my setup I was unaware of and that was affecting me on the side which I have since discovered and rectified too. This was that I was trying to run MV on an RPi 3B, not the required minimum 3B+. I hadn’t spotted the minimum requirements and didn’t realise it at the time, but the little 3B was becoming CPU bound and at times not responding to the http client before timeout. So I rectified that with moving to MakerVerse 1.1.5 (sorry I didn’t include the version # earlier) on another dedicated computer with more processing power.

I am now back up and running and I’ve just drawn a bunch of sharp, straight 90 deg cornered squares with my pencil attachment using hand-crafted gcode and my ruler says they’re good enough for me! :slight_smile:

I DID however try my spiral NC code again and it caused the sled to shudder around a bit for a few seconds then throw an ALARM3 at me again! But to be honest, I think that might well be something in the gcode itself and MV or the firmware not dealing with it too well. It was generated with makercam so it’s well and truly out of date. I will try another CAM tool and just ditch that file for now because when I tried my hand-crafted gcode again afterwards it still worked fine. Actually I’ll attach it to this for anyone who is interested or might like to try it on their own MV. But I have no desire to make the file work - it was just a test.

So there you go, I’m all go again! Thank you again gentlemen for your advice and even further research for me. I knew I’d get it licked :slight_smile:

Pete

spiral.nc (34.5 KB)


2 Likes

Pete,

Great news! Thanks for the follow-up. Sounds like you pin pointed your issue. There is a 51.30 hex out now as well… Too bad you have to recalibrate after a flash.

2 Likes

Yep cheers very much! But after getting it all going I decided to go back to WebControl again! This was because I’ve since come across a mention or two of you maintaining it going forward.

So I’m back on 51.27 now (eeprom wiped first of course), and all re-calibrated again - running WebControl 0.94 like the real cool kids do, and doing it on the RPi 3B-just-B-not-plus just fine too.

If you want someone to beta any changes let me know, I’m happy to give things a try and pretty proficient at getting myself into and out of messes :slight_smile:

Ps, that spiral drew fine when I did the cam in Easel too - NC attached for anyone who might want to compare

spiralEasel.nc (104.3 KB)

The .957 beta is out for rpi and Linux. I just got another windows machine and might be able to push a win 10 x64 version as well.

I’m going to move the beta release from my fork to the main repository, but if you look up the webcontrol 2022 thread, there is a link to the newer version.

2 Likes

OK that’s great! I can’t help with Windows testing - I’ve avoided using it my entire life. But I’m savvy with macOS and Linux so I’ll fire it up for a go. Meanwhile I’ve been happily drawing silly pictures of Wintergaten’s “Wilson” in pencil, and this morning I hacked together a “sharpie” (permanent marker) holder :slight_smile:


2 Likes

Nice sharpie holder! That’s looking great :grinning:

1 Like

Heh cheers Bar - it’s a bit “agricultural” as we’d call here in New Zealand, but it gets the job done! I’ve found there is a need to incorporate a spring to hold a small amount of pressure on the nib of the pencil or sharpie, and in the case of the sharpie, the pens also needs to have a slight downhill slant (thankfully already provided by the Maslow’s configuration) to enable the ink to flow to the tip.

I threw up some brown packaging paper and ‘plotted’ out a line drawings of Elsa for my young daughter.

The bigger it is, the longer it takes for her to colour it in! lol :slight_smile:

5 Likes

That’s BRILLIANT! It’s like a huge coloring book. Super cool.

1 Like

for people who like to do mazes, think of a maze that size :slight_smile:

My dad used to generate mazes on the work mainframe and print them out. I
remember my mom working them (wide fanfold paper where the maze could be an inch
high stack)

it would take forever to draw, but watching that happen would be half the fun.

David Lang

2 Likes

Kudos Pete (macgeeknz). I’ve always wanted a sharpie holder for my Maslow. I assume there is a spring somewhere.
Is the NZ term “agricultural” related to “chewing gum and bailing wire” construction?

1 Like

He he he, that’s not a term I’m familiar with but I suspect it means much the same. A more polite comment might be that I put ‘function before form’ in the design :wink:

There are in fact two springs - have another look at the close-up picture. They’re the two big silver springy looking things in the middle. There is also a piece of duct tape to stop the pen sliding out under gravity when not held against the workpiece.

I would happily share my SVGs, but it’s a very simple throw-together done in Inkscape and likely only suitable for my own Z-axis mounts and sharpie girth.

Ah, so “agricultural” is a complement paid to a McGyver-esque solution that would not win any awards for beauty. For example, an iPhone is not agricultural.

We say, “I farmer’d it,” or “macgyvered it” or “rigged it” similar to the agricultural reference. Another might say it was a hack: make it work, but it may not be pretty.

1 Like