OpenBuilds CONTROL Software

I'm having a problem.

Used the touch probe, everything worked good.

Shut down completely and later restarted program used touch probe, did't pay any attention and it immediately buried the tool 20 mm into the wood (default setting) instead of the .03 mm I originally set.

Do I have to always set the thickness?

I shut it right down because of the memory problem I have.

 

Ok

 

Peter,
I have been using the control for some time now and I really like the features and how easy software has been to learn and use.

I have only been working with machining for about 9 mounts now and I have to say that OpenBuilds has been instrumental in every aspect of my learning process.

I am a software developer by day and a hobby machinist by night. I would like to suggest a couple of features that may help others. These requests are just based on observations and by no means are they meant to take away from how great this software is.

It would be great if when loading a G-code file that the application Title bar would show the file name that is loaded. I often have a few versions of a project that I am working on and being able to see what file I am about to execute would be helpful.

I have a few macros that I have been using and the one wish that I have for macros would be the ability to execute the macro with a keyboard combination key press. I use a dedicated programmable key pad to jog my machine and being able to execute a macro from the keyboard would be great time saver.

My last wish would be for a simple cumulative Tab Delimited log file that would records the file name that is executed with the start and stop times. I am thinking that having the ability to automatically log run time would allow us to better understand the machining costs as well as provide data to develop a maintenance schedule. Over time I have found that cretin items need periodic maintenance to continue to function. IE: Router Brushes. It is the worst feeling to spend hours machining something and have the router fail a few minutes before the end of the machining process.

I know that the log file may be a big ask and another solution may be to simply add a field that cumulatively records the time the tool is running in minutes and provide the ability to reset the count.

Thank you again, for all that you do to support this great program!

Regards,
Mike

 

You might want to specifically try Debian, as I saw a couple threads suggesting it may be related to some extra security precautions that other distros don't take. And I have no idea what that means for any of the Debian-derived distros.

You... you blame... us? *sniffle* But...but...but... you never asked! *cries* We thought you didn't care about how we actually use the probe function lol.

(Pssst! Quick, guys... I've got him feeling guilty! now's the time for those feature requests!)

Well, you could run multiple versions. Except that one would keep trying to delete itself every time you launched it. :/

In any case, a little experimentation makes it looks like the problem has something to do with the file naming:

If I run the original "OpenBuildsCONTROL-1.0.207.AppImage" file as-downloaded, it'll be renamed (or deleted & replaced - I'm not entirely clear on which) with "OpenBuildsCONTROL-1.0.213.AppImage" (ok, fine, "1.0.215") , thus breaking anything & everything that was pointed at the filename (hard links may be an exception - that's where the distinction between rename vs delete & replace could be significant).

On the other hand, if I first rename "OpenBuildsCONTROL-1.0.207.AppImage" to, say, "obc207" and let that run the update, the new version will still be named "obc207", thus preserving any filename-based references.

As something of a traditionalist, I'm inclined to think manually adding something like AppImages to application menus is probably the Wrong Way to treat them in the first place (but then, where should you place & run a "portable" version of an app on Windows? It doesn't really belong in the system-managed Program Files directory, but anywhere else seems... so... untidy) but desktop shortcuts are another matter - and those would break in exactly the same way on Windows if you renamed the underlying executable like this.


[ To be continued! ]


-Bats
(not that there's anything Wrong with doing things the Wrong Way)

 

Yikes!

This sort of thing is exactly why my touch plate dimensions change over time


-Bats
(mind you, most of "this sort of thing" came from problems with my own sketchy probe routines)

 

I suppose the problem isn't really that it's impossible to flatly refuse to ever update - or even that the dialog is too easy to accidentally close...

I think the core problem is that "Not right now" (also being the default "I didn't click on, or even see the dialog" behavior) doesn't mean what it usually does - ie, "Don't do anything right now, but give me another reminder like this later". Instead, it means "Make this dialog box go away, and then update without telling me as soon as I quit".

If that were fixed - so that the default behavior is "keep pestering me, but don't touch anything" - it takes the wind out of all my other gripes about the dialog.


-Bats
(because a gripe is much easier to ignore without wind in it. like a vuvuzela.)

 

This would be extremely handy (and it's something I half-miss from Mach 3... although their full-path-in-narrow-window implementation usually meant that the important bits - like, say, the filename - would be truncated anyhow) but it might be a little more complicated than it seems at first glance, since CONTROL (at least on the UI end) doesn't really seem to deal with the concept of an "open file", so much as it has a workspace that it's possible to read the contents of a file into, or save out to a file. I really like the way this works - it makes it much quicker to just whip off a couple quick lines of code - or to make some experimental edits to something that doesn't seem to work quite right - without worrying about where to save it, how to keep track of the different versions of the file, or whether or not something else is trying to open the same file at the same time. At the same time though, it makes the "file name that is loaded" a bit ambiguous.

Of course, by the time I hit 'Send', Peter will probably have already explained why I've got it all backwards, it's simple, and he's just pushed it out in .216. or .218. Or whatever he's up to.

This would be great. I keep wishing I could drag/pin macros to the toolbar, but being able to assign them hotkeys would be almost as convenient and probably a whole hell of a lot simpler to implement.

This might run into some of the same complications as the first proposal, but I suppose there's no reason it couldn't log the fact that xyz.gc was loaded, and then that a program was run, leaving it to the user (or whatever script they feed the log to) to decide whether the two should be considered the same file.

Either way, I'll click Like on this one, too, just because I'm a huge sucker for logging, and it's something I'd really love to see a lot more of in CONTROL - the ability to pipe the console output to a file would be a nice start, and the first million options for log content/formatting seems like a pretty reasonable milestone. Even being able to set the console buffer length would be something - that big $$ settings dump* that grbl does every time you clear an alarm causes it to fill up in a hurry.

That would probably address your issue of brush-life tracking, but it might not be so broadly useful - say, for users hoping to monitor things like wheel or belt wear, or coolant usage (although I would hope they could find a more direct way to watch the latter).


-Bats
* err... that's the big dump of grbl's "$$" settings - not a "big *$$ dump" of settings, nor a big dump of "*$$ settings"

 

Good news! I found the cure!

No, not that cure - those were entirely different bats. We don't talk much to that side of the family.

And it's technically not a cure either, so much as a workaround (alternative approach? different download?).

But, details aside, I did finally get CONTROL working on Debian again. While the .215 AppImage is still broken, the .deb installed & (so far) seems to be behaving nicely. Mostly.

Mostly...

There's just a teensy little problem with the icon.

This is more or less what my desktop looks like when I open up the Accessories category in the applications menu:

(please ignore the "OpenBuilds CONTROL" entry for now - that's one I made manually for the AppImage version)
(please also ignore the abject lack of customization. it feels a little like being seen naked. minus the screaming.)

And this is what my desktop looks like when I move down a few items to Graphics (where CONTROL chooses to place itself - go figure) :


It's a little hard to spot, but if you look closely you might be able to tell that the CONTROL icon isn't quite as teensy as all the other icons in the menu.

I don't know how much of this is debian and/or xfce-specific, but /usr/share/applications/openbuildscontrol.desktop specifies "Icon=openbuildscontrol". I have no idea how xfce gets an image from that (the only "openbuildscontrol" without an extension being the main binary, which doesn't look much like an image file), but something's obviously a little wonky about it. Replacing that line with "Icon=aRealActuaIImageFile.png" (I used the openbuildscontrol.png that I extracted from the AppImage's squashfs) seems to return everything to expected behavior.

Curiously enough, while the problem is a huge image, it doesn't seem to be an image size issue causing the problem - the png from the AppImage is quite large too, but gets scaled down without complaint.

[edit: on the off chance anyone else is trying to fiddle with this on their own, I should probably mention that I copied the original /usr/share/applications/openbuildscontrol.desktop to ~/.local/share/applications/ and edited that one (which overrides the system-wide version, without the risk of making a mess of it) ]

I suspect you've probably got a better idea what's going on here than I do, Peter (seeing as it's probably been a decade since I could claim to be competent with linux, and twice that since I did anything professionally), but give a yell if I can help testing anything (whether this, or any of the other crap I seem to keep breaking).


-Bats
(hey, at least this problem I was able to fix. mostly. sorta?)

 

One last observation on the AppImage vs .deb bit:

When the AppImage was launched, it would stick a little icon in the notification area (or whatever you call the equivalent of the windows systray). A right-click context menu gave a choice between launching the UI & quitting the whole works. Closing the window would effectively just minimize it back to the icon - it took a right-click + quit to actually exit.

The .deb version dispenses with that & just opens and closes the UI directly, like a normal application.

I don't know whether this distinction is intentional, a bug, or if it even makes the slightest functional difference, but I figured I'd mention it anyhow, since it's past my bedtime and I'm clearly not getting anything else useful done tonight.

[edit: I think there may be something buggy going on after all. After "quitting" the .deb version, I noticed the process was still active. Launching it again brings the same instance (or at least an instance with the same console log) back up. Aside from killing the process, I don't see any obvious way of actually quitting. For what it's worth, this is on *.215 - I haven't tried ripping it out & reinstalling *.207 to see if it does the same]

-Bats
(as opposed to earlier, when it was before my bedtime and I was clearly not getting anything useful done)

 

I don't see the Cinnamon desktop on that graphic anywhere.

Currently can't get control to open a port on my Linux mint installation. Still triaging as a lot of variables have changed. Any changes to this with 215? It whines about --no-sandbox if I try to run it as root which I think I had to before to get it to open my ports. Last version I ran was something like 200. Note there has been a Mint release update in there since. And I've been working on the whole setup so, lot of variables have changed. But if anything springs to mind please let me know.

 

Hi Guys!

I have been trying to install OpenBuilds Control on Raspberry Pi for 2 days.
I know that the project has no official support but I give up - maybe someone can help me here.

I did everything in accordance with the instructions.
After using the node index.js command, nothing else happens.

Ie the OpenBuilds Control application window does not appear.
After entering 127.0.0.1:3000/jog in the browser window, I have access to OpenBuilds Control, however, after connecting the BlackBox board with RPI with a USB cable, I still see the message "Waiting for USB"


I have no ideas anymore.
I formatted SD cards, performed the installation several times and the same problem every time.

 

I'll try the dialout thing. I'm not wedded to Mint or even Debian. What is the preferred distro for linux?

 

Dialout group fixed it. Thanks!

 

I just made a local .desktop pointing at the (huge, but gracefully resized) .png I found in the AppImage -we'll see how it holds up after the next update, or if anything needs fancier fixing.

I'm still a little puzzled by where the .deb's image actually is, though - as the only file on the system matching the Icon= line in the .desktop file seems to be the binary itself... or is that "binary" something weird - like the AppImage archive with a squash'd file system hiding inside it - that linux understands how to pull an icon out of, even if I don't?


-Bats
(I'm a little puzzled by lots of things, though... and more every time I make the mistake of turning on the news)

 

I'm hardly wedded to xfce - it's just the thing LinuxCNC happened to dump on their Debian install package, and, as I heard someone describe it quite eloquently once, "I want to spend my time using my PC, not making it work" (never mind making it work like some 93% a pie chart seems to think it should).

But wow... I remember when Afterstep was the hot new thing & Enlightenment was the ultimate in flashy.

I feel old.

But now there are two of us! Strength in numbers, baby!

I'll see if I can take a poke at it - although at first glance it looks like making use of that link is going to require figuring out how electron builder works in the first place, so it probably won't be a quick answer.


-Bats
(wait... but what if I want to use my software rather than "making it work"? now I'm all confused again...)

 

You're gong to regret saying that when I finally get around to dumping the whole list there

I agree, it shouldn't (after all, that's what I keep whining about)... and yet it does. This is the stdout (and just a little stderr) from a run of *.207 where I launch, click "Not right now", then close the window & quit the app :

Spoiler: Update Log

bats@puzzlebox:~/OpenBuildsCONTROL$ ./OpenBuildsCONTROL-1.0.207.AppImage
Starting OpenBuilds CONTROL v1.0.207
Local User Data: /home/bats/.config/OpenBuildsCONTROL
Command Line Arguments for Electron: Set OK
https: listening on:10.0.0.212:3001
http: listening on:10.0.0.212:3000
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
Created Uploads Temp Directory
Checking for update
Found version 1.0.215 (url: OpenBuildsCONTROL-1.0.215.AppImage)
{"version":"1.0.215","files":[{"url":"OpenBuildsCONTROL-1.0.215.AppImage","sha512":"RSkJcHjwCa5IoERFjYns/RrsnM4vEgs52Hg/Mriwf5M1rBrFEp+HVftfND/7xBmbjRpk8D/CsQflwlM8ybGo+w==","size":100396018,"blockMapSize":105478}],"path":"OpenBuildsCONTROL-1.0.215.AppImage","sha512":"RSkJcHjwCa5IoERFjYns/RrsnM4vEgs52Hg/Mriwf5M1rBrFEp+HVftfND/7xBmbjRpk8D/CsQflwlM8ybGo+w==","releaseDate":"2020-03-20T14:13:08.565Z","releaseName":"v1.0.215","releaseNotes":""}
Downloading update from OpenBuildsCONTROL-1.0.215.AppImage
updater cache dir: /home/bats/.cache/openbuildscontrol-updater
Cached update file doesn't exist, directory for cached update will be cleaned
jcoaC2XHS01kxOeYX3atjgko duplicated in blockmap (same size), it doesn't lead to broken differential downloader, just corresponding block will be skipped)
oypxBdLHAOvlbVxZm4C9vbkA duplicated in blockmap (same size), it doesn't lead to broken differential downloader, just corresponding block will be skipped)
File has 4751 changed blocks
[
{
"kind": 0,
"start": 0,
"end": 159006
},
{
"kind": 1,
"start": 159006,
"end": 70653605
},
{
"kind": 0,
"start": 60568607,
"end": 60674518
},
{
"kind": 1,
"start": 70759516,
"end": 89048373
},
{
"kind": 0,
"start": 78622382,
"end": 78717127
},
{
"kind": 1,
"start": 89143118,
"end": 89314963
},
{
"kind": 0,
"start": 78888941,
"end": 78930951
},
{
"kind": 0,
"start": 78622382,
"end": 78655150
},
{
"kind": 1,
"start": 89389741,
"end": 89960676
},
{
"kind": 0,
"start": 79534583,
"end": 79623003
},
{
"kind": 1,
"start": 90049096,
"end": 90230240
},
{
"kind": 0,
"start": 79804146,
"end": 79895767
},
{
"kind": 1,
"start": 90321861,
"end": 90623783
},
{
"kind": 0,
"start": 80197705,
"end": 80282618
},
{
"kind": 1,
"start": 90708696,
"end": 95428197
},
{
"kind": 0,
"start": 85467641,
"end": 85499603
},
{
"kind": 1,
"start": 95460159,
"end": 99849139
},
{
"kind": 0,
"start": 103487987,
"end": 103729241
},
{
"kind": 1,
"start": 100090393,
"end": 100290536
}
]
Full: 98,042.99 KB, To download: 96,990.16 KB (99%)
Differential download: https://github.com/OpenBuilds/OpenB...d/v1.0.215/OpenBuildsCONTROL-1.0.215.AppImage
download range: bytes=159006-70653604
Redirect to https://github-production-release-a...37859794/6becbd00-6ac5-11ea-8d27-4317ba000d2e
download range: bytes=70759516-89048372
download range: bytes=89143118-89314962
download range: bytes=89389741-89960675
download range: bytes=90049096-90230239
download range: bytes=90321861-90623782
download range: bytes=90708696-95428196
download range: bytes=95460159-99849138
download range: bytes=100090393-100290535
New version 1.0.215 has been downloaded to /home/bats/.cache/openbuildscontrol-updater/pending/OpenBuildsCONTROL-1.0.215.AppImage
exit
Auto install update on quit
Install: isSilent: true, isForceRunAfter: false

bats@puzzlebox:~/OpenBuildsCONTROL$

...after which the OpenBuildsCONTROL-1.0.207.AppImage file has been replaced by OpenBuildsCONTROL-1.0.215.AppImage .

This is (obviously) the AppImage version - I haven't done much update testing on the .deb (both because it's a little more work than just recopying a file, and, well, because updating it didn't break anything), but I can give it a try if you think it's likely to be different - or matter.

[edit-from-the-future: I just tested the Windows version before replying to adam.v's question, and the behavior is the same there]

But would downloading a Win 10 ISO be any easier?

What pings? Yikes! I haven't seen something like that since, after gnawing through the insulation, squirrels did something to the top of the conduit on the utility pole, leaving the whole thing open to fill with water whenever it rained. It took Comcast four visits before anyone bothered looking at the pole - and when they did, they got a face full of stagnant water when they popped open the lower end of the conduit. I'd say they deserved it, but the guy who got it was the first one who'd actually made an effort to find the problem.

Ouch! Guess the US isn't the only country that utterly botched the fiber rollout - but at least we've got the cable monopoly to sodomize us in the absence.


-Bats
(a ping without a pong is just screaming into the void... and yet, a pong without a ping is still a pretty good game)

 

I don't know whether it's applicable to RPi, but it sounds a lot like what I'm seeing with on debian/xfce. Normally (with the Win & linux AppImage) running the binary pops an icon in the systray/notification area, but with the .deb version, the icon ain't there, and it appears that nothing happens. Launching it a second time - whether from the GUI or from a second terminal (and without killing the first) - will bring up the window.

-Bats
(I had some advice on the second part of the problem too... but I figured it wasn't very helpful, seeing as it turned out to be completely wrong)

 

I want my PC to work the way I tell it to, not the way Microsoft's latest force-fed update wants it to.
I've never been onboard with the whole "software as a service" model, and extending it to an operating system just makes me cringe - even if it weren't for some outstanding questions about privacy or the quality of those updates.

At the same time, I had a lot of the same feelings after crashing out of the tech world - XP ended up replacing linux as my daily driver, and Win 7 replaced that, to the point where now I find myself resorting to man pages just to use vim... but Microsoft really went [back] off the rails after that. 8 was a mess, and 10 I have too many fundamental objections to to even install. Right now linux only runs on my CNC box (replacing the XP install that ran Mach 3, and in preparation for a potential move to LinuxCNC), but I'm stuck seriously considering a serious move back, even if getting this machine switched over has done absolutely nothing to make me enthusiastic about the prospect.

Electron builder is so getting fired!


-Bats
(retired linux evangelist)

 

I want my PC to work the way I tell it to, not the way Microsoft's latest force-fed update wants it to.
I've never been onboard with the whole "software as a service" model, and extending it to an operating system just makes me cringe - even if it weren't for some outstanding questions about privacy or the quality of those updates.

At the same time, I had a lot of the same feelings after crashing out of the tech world - XP ended up replacing linux as my daily driver, and Win 7 replaced that, to the point where now I find myself resorting to man pages just to use vim... but Microsoft really went [back] off the rails after that. 8 was a mess, and 10 I have too many fundamental objections to to even install. Right now linux only runs on my CNC box (replacing the XP install that ran Mach 3, and in preparation for a potential move to LinuxCNC), but I'm stuck seriously considering a serious move back, even if getting this machine switched over has done absolutely nothing to make me enthusiastic about the prospect.

Electron builder is so getting fired!


-Bats
(retired linux evangelist)

 

I installed the most recent update yesterday for the OpenBuilds Control software and now it won't open. Anyone else having this issue? and any way I can go back to the previous version? Thanks!

 

What are you running it on, and what exactly is happening? I haven't heard about any trouble with the new Windows version yet, but there've been some minor hiccups with the linux one (as the last few pages of the thread will attest) - at least if you use Debian and/or xfce. Short version (I can expand if it's relevant & you don't want to dig through the past couple days of back & forth) is that the AppImage version is broken on Debian (and presumably at least some Debian-derived distros). The .deb version more or less works, but (at least on xfce and maybe Raspian) the background process doesn't add the icon it's supposed to, so you have to launch it twice to get the window to open.

You can get the installers for *.207 (before the recent dependency changes) off the git repository here, but it'll still try to update itself when you launch it. If you want to block the update, every time you launch it you'll have to go to the Serial Console tab and hit "Cancel" before the 10 second countdown finishes. Waiting for the popup & clicking "Not right now" will just wait and update it as soon as you quit (it sounds like this is probably unintentional, but it happens on the Windows version and at least one of the two linux versions).


-Bats
(something must be broken in this reality... Now I'm the one giving the short version)

 

Dell XPS 15 laptop, 16GB ram, Windows 7. I have a felling the Windows 7 is part of the issue, but it ran the previous version with no issues.