OpenBuilds CONTROL Software

Hey guys, my apologies if I missed this in the earlier pages...I ran into an issue 3 times this evening where my machine (lead1010 with black box) would stop mid-way through a program but without any errors. It stopped at different places/times each time. My assumption is that this is a USB communication issue, but I thought I'd see what you think. The machine is bone-stock and I'm running OB Cam and Control. Have you seen this before? When the machine would stop working I couldn't stop the program or use the jog features, I had to turn off power to the machine. Is this a computer issue on my end or is this something that has come up before? I love this machine to death but this was a tough night with it...

 

David, thank you so much for the quick reply, I really appreciate it!
You are 100% right, the power plan on this laptop reverted to the original settings. I wasn't aware that it could happen unless done manually.

Thank you again! I'll be running parts again first thing in the morning

 

Reading posts and said to try reflashing

 

Hi, I don't know if this is the best place for this post.
Recently OPENBUILDS software has implemented the probe function. Is there any idea or prediction for the implementation of autolevel?

 

Thanks, when I need autolevel I use bcnc, but I really like the simplicity of the openbuilds control software.

 

Looks like I've got something a little wonky happening with the autoupdate (possibly because I haven't quit for a week or three, so it hasn't had a chance to to get beyond 1.0.0.215)...

The serial console shows:

Code:

[19:31:34] [ autoupdate ] Starting update... Please wait

[19:31:34] [ autoupdate ] Error in auto-updater: Cannot check for updates: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'

And stdout/stderr shows:

Code:

[07:31:34]  Checking for update
[07:31:34]  Error: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[07:31:34]  (node:23268) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[07:31:34]  (node:23268) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[07:31:34]  (node:23268) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
[07:31:34]  (node:23268) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)

It's nothing I actually need fixed (worst case scenario, I could manually reinstall if I ever get to the point of using it for anything other than endless M3 -> [RF noise] -> M5 ->lather/rinse/repeat frustration) - just figured I'd report it on the off chance it was useful.


-Bats
(failing to escape from noise)

 

This is an important point that I don't think enough people appreciate!

 

For reasons that are now fuzzy, I grabbed the .234 .deb shortly after posting here, and installed it over the top of the existing one. Everything seemed to be behaving normally for a day or two, but then I noticed the errors had popped up again - at least sometimes. I only spotted it once out of a couple days of use (although it did turn up again when I restarted just now). It also picked up a new warning from node.js, but that may be unrelated. Here's the latest stdout/stderr dump:

Code:

[11:07:27]  Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
[11:07:27]  ATTENTION: default value of option force_s3tc_enable overridden by environment.
[11:07:36]  (electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check https://github.com/electron/electron/issues/18397
[11:07:49]  Checking for update
[11:07:49]  Error: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[11:07:49]  (node:20889) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[11:07:49]  (node:20889) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/opt/OpenBuildsCONTROL/resources/app-update.yml'
[11:07:49]  (node:20889) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
[11:07:49]  (node:20889) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
[11:07:49]  (node:20889) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
[11:07:49]  (node:20889) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I don't know whether I'm the only one this is happening to, or if I'm just the only one noticing - staring at the console apparently isn't an especially popular pastime, and I would never have even seen the stdout part if the great CONTROL/Xfce feud didn't have me stuck launching from the command line. If it's just me, I'm perfectly fine with manual updates (which I imagine comes as a huge shock, right?), but if you think it's important / worth it / likely to tell you anything you don't already know, I can try ripping it all out & doing a clean install.


-Bats
(Manual Updaters Union, Local 235)

 

Yep - same thing I'm dealing with - I think that may have been when I initially moved my launches to the command line, so I could keep an eye on what was happening. Usually fire it up in one terminal, tee the output to a log, leave that running, and then move to another terminal to run it again & get the GUI open.

Yup, that's the one.

I'm on Debian, but it's the xfce that gets us both in trouble. Peter hates me for it

(I've actually been meaning to try switching away from it, in hopes of getting some other options for handling mouse focus... but migrating and getting everything reconfigured seems like an awful lot of work for something of such low priority)

Yup. Peter told me he did that deliberately, so we'll always have a reminder of how much he hates us.



-Bats
(he hates us thiiiiiiiiis much *throws out arms in a gesture approximating the size of a huuuuuuge icon*)

 

Win users (and most linux users, for that matter) wouldn't be able to see the stdout/stderr stuff, and probably wouldn't notice there was a problem at all, unless they happened to be watching the console tab when it happened... And these are windows users we're talking about - they don't do consoles.

I'm also a little curious about why I didn't see it happening more often - doesn't the update check run something like hourly now? If it only happens rarely, or only happens on startup, that would limit the visibility (and impact) even more.

Oh no... not.... UPSTREAM? *shudder*

I'll see if I can give it a wipe today or tomorrow, then... whenever I manage to wrap up the (now-belated) mother's day crap.

If things keep working that long.

*fingers crossed*

*legs crossed*

*eyes crossed*

See, David! He hates us!

Finding the problem was easy. It's finding the cause that's slowing everything down.


-Bats
(what do you mean "what about the solution?" - that's someone else's department)

 

A couple other quick items that I noticed recently (present in .234):

• The increase/decrease jog increment key bindings only work in mm mode, not in inches (although the rest of the bindings still seem to operate normally). This may be a long-standing issue, since I have notes from a month or so back about +/- being intermittently broken (although at the time I didn't manage to associate it with the mode)
  
  
• After using the Clear button in the g-code editor (or manually deleting all the code & then hitting update), the 3D View tab's title sits with an endless progress spinner on "rendering, please wait" until some code (movement codes, specifically) is entered & the view is updated again. This is probably just cosmetic.
  
  
• The OK button on the probe success dialog doesn't have focus (unlike most of the other dialogs now - thanks for that, btw)
  
  
• Error dialogs (and the clearing thereof) isn't synced between desktop & mobile interface. So it's possible to clear a dialog on one and have it still sitting on the other - then, when you go to clear the second one, it resets everything all over again. Particularly a problem if you start a program running on desktop, then pick up the tablet & walk away, only to later discover that it's occupied by a (now obsolete and irrelevant) dialog you can't get rid of without wrecking the whole process.
  
  
• F6! F6 F6 F6! Yay for F6!
  • Seriously - thanks, Peter. I don't know when you snuck it in, but being able to jump to the console input - especially from other tabs - is really awesome.

-Bats
(now all I need is remappable gamepad support with configurable jog curves. that should be easy too, right? hello? Peter? why is everyone laughing at me?)

 

Oh, it keeps the auto-update from happening... but how long does it take for someone to report that they didn't get an update they didn't know was coming?

I am curious if the one failure somehow blocks future scheduled attempts from running, though... that's about the only reason I can think that I didn't see more incidents in the log.

Speaking (tangentially) of logs... is there any chance of getting a longer console log of some sort? Writing everything (optionally or by default) to a log file would be fantastic, having a longer buffer would be helpful, or, failing that, pointing me in the vague direction of the variable controlling said length. The problem I have right now is that it takes just over two of grbl's status dumps (ie, a single Stop + Clear Alarm) to scroll everything out of the buffer.

I blame the Novell part - I don't remember SuSE having any particularly negative associations before they came along.

Of course, I don't remember much of that era - it's all a bit of a drunken blur overlaid with spinning psychedelic fractals - but it was always harder to hate the smaller companies than the big ones.

Will do.

[edit: done]

Shows how much attention I've been paying... I only noticed the tooltip a couple days ago.

Although I suppose I wasn't really leaving the console input until around recently either, so that may have something to do with it.


-Bats
(M3, M5, M3, M5, M3 [profuse profanity] M5)

 

Ahh - I remember Novell - a whole shelf in the bookcase for the manual!
Alex.

 

I gave my machine a few weeks off and when I came back, I can no longer run a job. The CNC homes and jogs with keyboard and mouse but when it comes time to run the job, it moves into position, starts the router, and freezes. Meanwhile, the software is blowing through commands but nothing is moving.

When I powered up, I updated to 235 from 230. Thinking that might have something to do with it, I went back but no joy. I have tried different computers, jobs that ran before, etc. Black Box and Openbuilds Control has been working great so I fear i'm overlooking stupidly obvious. Any suggestions for what an old hacker might try next?
Russ

 

Thanks Peter, I will upload the part file when I return. The DRO updates as the commands are processed even though there is no movement on the machine. I looked through the serial log but didn't see anything that looked suspicious. I can give you a look at that too.
Russ

 

Run a built in script like surfacing or z probe?

 

Great idea, Dark Penguin! Work with a known entity like the flattening wizard. I put a scrap on the machine, generated the flattening code, and it turned the router on, sent the Z to the correct depth and froze. All the while, commands were being processed but no movement.

I put all the code in a file so I could copy and paste them one-by-one through the serial console. I set it up an "air cut" and copied each command except for the M3 to turn the router on. All X, Y, and Z movements worked as they should. For grins, I disconnected the IOT cable from the Tool port on the Black Box Controller, turned the router on manually, and ran the job without a hitch. I think I've stumbled onto a work-around but I'd really like to use the IOT relay to turn the router on and off. Given that they both sort of work, I'm not sure how to go about getting them to play nicely together again.
Russ