OpenBuilds CONTROL Software

A Stop Job on this system appears to be an infinite deceleration event from a control perspective. No machine can physically achieve such a high deceleration and with open loop stepper motor control there would be no way of knowing if, and how many, steps were skipped during deceleration.

 

Jamin's at least half-right on this one. If you pause first and then stop, you can cleanly pick up from there without re-homing. If you hit stop while the machine's in motion, though, it's basically the same as Abort.

The fact that we're having this discussion suggests the UI's less than intuitive about the behavior of Stop & Abort (after some preliminary testing I spent my first few days convinced that they were - whether intentionally or otherwise - identical). I'd rather see the Stop button execute a Pause-then-Stop. It would make the function of the two buttons less ambiguous, and would make Stop's behavior consistent across the board, rather than sometimes being safe and sometimes losing position.

I've had some other thoughts on BB/CONTROL stopping/not stopping conditions, too... but those are going to have to wait until they can be extracted from a cloud of blistering profanity.


-Bats
(so, maybe next week? the weekend's forecast is looking cloudy with a chance of **** **** ****)

 

Bat....based on what I experienced I don't think you can hit pause and then stop and then hit run and continue where you left off. When I did the sequence of pause then stop the coordinates changed so by hitting start again who knows what the machine will do like I found out the hard why by trying to return to work home.

I'm confused as to the difference between stop and abort.

 

Very strange - I actually tested it on mine just before posting, to make sure it worked the way I thought it did.

I'll give it another try tomorrow, just in case I was hallucinating last time.

I was confused, but then I figured it out. Or thought I did. Now I'm confused all over again.


-Bats
(operating machine tools while confused & hallucinating? don't try this at home, kids - Bats is a highly trained idiot)

 

I went ahead and reverted back to version .202 randomly just to see if hitting "pause" then "stop" would would change the coordinates and it didn't. I was able to safely return to work zero after stopping the job. In version .207 (at least for me) my coordinates change when hitting "stop job".

Edit: Reinstalled 207 and everything seems to be working now. Probably a glitch on my end?

 

Most likely someone else already asked that question but I could not find an answer with the help of the search function: How can I switch the units used in the openbuilds CONTROL user interface between inch and mm?

 

New Z Probe wizard is only showing an option for the Openbuilds Z Probe. I am using a plate and there is no obvious way to change it.

 

Yes, it shows the Z Touch Plate Wizard

 

Yeah that is the one it shows. No way to have an option to show the previous probe options?

Is there going to be support for others or just the one that we have to buy from you?

 

I may have clicked "Like" on that update announcement a wee bat a wee bit too soon (in my defense, I was really excited to try it out).

I haven't gotten to check it out for myself yet (more on that in a minute), but from the way it's described, not being able to set touchplate thickness is going to be a gamebreaker for me. There are a couple different reasons for this:

1. ) I'm actually right in the middle of making myself a new touch/corner plate, and there's a fair chance it'll end up being a different thickness than the one in the shop (probably a very good chance, considering the stock I'm cutting it from is about 1/3 the thickness - although it wouldn't be the first time the very laws of physics have warped and distorted themselves in impossible ways just to confuse or confound me - and because having a low-profile plate - to allow for thick workpieces with limited Z travel - is half the point of the exercise)
   .
2. ) I do, in fact, still have & frequently use one of the Openbuilds-style touch plates, but, while I don't know what sort of additional QA/QC you guys do before shipping your stock, the ones I've gotten from ebay/amazon in the past have shown considerable variation in thickness (one even had a visibly crooked plate on top), so there's no guarantee that mine has the same measurements as yours. [my personal issues aside, this is likely to turn into a support headache too, as different users with "one just like that!" may not see the same results from a stock setting... Unless of course OpenBuilds wants to do a major pivot from the traditional open sourceyness (sourceiness? sauceiness?) to "OpenBuildsCONTROL™ supports only officially licensed OpenBuilds©-brand hardware, stamped with the OpenBuildMark® holographic serial number seal of OpenBuilds™ Proprietary©® Openlicensedness℠ "...but that'd be silly, and would require far too much complicated punctuation ] [...and everyone would confused the OpenBuildsMark with Mark from OpenBuilds, even if they look nothing alike]
   .
3. ) If my OB-ish plate was the same thickness as the OB, it isn't now - and I can't imagine I'm alone in this, either (well, alone in admitting it, maybe). After a couple years of dealing with clueless, careless, and reckless operators (who I assure you look nothing at all like me, and probably don't even wear the same color safety glasses!) and occasionally unpredictable software, I've had to resurface away the damage more than once - which, of course, requires new measurements & a new thickness setting each time. On the brighter side, this might open up a new market for selling bulk packs of touch plates as a consumable.
   .
4. ) When I'm working with metals (or any other conductive stock, like, errr... metals, I guess), I prefer not to use a touchplate, and probe to set zero right on the workpiece itself (sometimes for convenience, other times, as with 1), because there's no room for a 2cm doohickey in between the tool & workpiece) . This was simple with the prior version - just use plate thickness = 0 - but if it's locked into a specific make & model of plate, that's going to be a problem.
   .
5. ) Because, um, I suppose I could just do all my probing manually in the console (where I seem to be spending most of my time anyhow) or with a macro, and, but, err... well... I'm pretty sure there was a perfectly good reason to insist on a wizard when I started typing. Probably. Ok, so, fine, maybe I should downgrade that from "gamebreaker" to "inconvenience" (or "insufferable indignity"?), but I do still think it's a mistake to lock it to any particular plate dimensions (defaulting to the OB plate dimensions, on the other hand, makes perfect sense... although I've also found myself wishing it would just remember the settings I used from the previous run)

Of course, I'm probably getting way ahead of myself here, since, as I sort of hinted at before, I haven't actually been able to see the changes for myself. The Windows version (which, unfortunately, is on a machine nowhere near The Machine) seemed to update happily enough, but the AppImage version I was running on linux (the Debian Stretch w/RT_PREEMPT distro that LinuxCNC uses) seems to be broken. It replaced the file itself (without a backup, which was a little inconvenient) but didn't restart, and on running the new one I get:

Code:

bats@puzzlebox:~/OpenBuildsCONTROL$ ./OpenBuildsCONTROL-1.0.213.AppImage
[1049:0319/165216.431778:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_OpenBu5Zr8aW/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

I've seen a (less than ideal) "--no-sandbox" flag suggested as a workaround for what seems to be the underlying Electron issue [very long thread here, of which I've skimmed almost none, as I'm only almost sure I understand what Electron even is], but while that eliminated the error message, CONTROL still fails to start (or at least to open). All I get is:

Code:

bats@puzzlebox:~/OpenBuildsCONTROL$ ./OpenBuildsCONTROL-1.0.213.AppImage --no-sandbox
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"

...and then an endless (or at least not-yet-ended) wait. No window, no icon in the notification area/systray. The process floats around 1-2% of CPU load (it was usually at least 15% when working), with around 123MB (RSS) allocated (although this will gradually creep up to around 127MB over several minutes, before dropping back to 123MB & starting to creep again, which looks a little loopy).

Another issue I ran into (admittedly, less critical) is that, because the update downloads a new AppImage with a new version number in the filename, any menu items, desktop shortcuts, symlinks, etc, that pointed to the program will be broken after the update. I haven't gotten around to trying out the *.deb version yet, so I don't know if that'll behave any differently.

And, last of all, there's the update dialog... No sir, I don't like it.
(and I know that sounds really petty, but bear with me)

1. ) There's no "No." option. There's "quit everything and do it now" or "wait until I quit and then do it quietly behind my back. Aside from being creepily Microsofty ("Hi, I'm Clippy! I'm going to helpfully upgrade your machine to Windows 10 at gunpoint, whether you like it or not!"), this isn't a terrible sin when everything goes right. If the update process goes smoothly, the new version works as well as the old one, and there haven't been any features removed, no harm done. But, as we're seeing here, everything doesn't always go right, and updates can change the user experience in ways that not everyone will always be thrilled about. Watching the serial console to cancel the ten second countdown isn't really a viable alternative, especially for users who don't even know an update's coming.
   .
2. ) The update process deletes the old version (with, as far as I could tell, no backups made) before checking whether the new one successfully installed. This has absolutely nothing to do with the dialog, but it had a "2)" in front of it, so I figured it had to go between the "1)" and "3)". It is a problem, though.
   .
3. ) As it turns out, the "Not right now please" and "Ok, Proceed with Update" are not the only ways to dispose of the dialog. Clicking anywhere else in the CONTROL window will also close the dialog (but not cancel the update - it basically defaults to the "Not right now" behavior). If CONTROL happens to be partially obscured by another window and you click to raise it & see what that popup is all about? Yeah, it'll go "poof" - you'll be left none the wiser, and have no idea why everything's suddenly broken the next time you go to launch it. This is pretty much what happened to me today - the big difference being that I already knew a new version was supposed to be getting pushed out, so I had some spoilers about what was likely to be happening.

Needless to say, I'll apparently have to stick with *.207 for the time being - but is there any way to keep it from trying to re-update itself every hour (and then proceeding to delete the working version on quit)?


(also, I feel awful about dumping on the update like this, because I was really looking forward to it. seeing the v1.0.210 note about focusing on the close button made me far more excited than it really should have. this may say something about the number of alarms & errors I provoke out of my poor machine)


-Bats
(It's not that I'm resistant to change. I like change. The problem is, change is terribly allergic to bats, and the last thing anyone wants to deal with is change sneezing)

 

Just updated to V1.0.214
I have noticed that after prob is completed when you hit okay the Z axis drives down not up. This is bad because the bit is on the probe when it tries to drive further down.

 

Just a correction to my last post. V1.0.214 when probing once the prob cycle is started is slowly drives down. When it finds the prob it then tries to drives down further at a higher rate of speed without the user doing anything. because the bit is on the prob it crashes the z axis.

 

The log from the prob cycle.
[10:05:32] [ $J=G91G21Z10F4978 ] ok
[10:05:51] [ G21 ] ok
[10:05:51] [ G10 P1 L20 Z0 ] ok
[10:05:53] [ G38.2 Z-25 F100 ] [PRB:-620.472,-620.753,-6.496:1]
[10:05:53] [ G38.2 Z-25 F100 ] ok
[10:05:53] [ G4 P0.4 ] ok
[10:05:53] [ G10 P1 L20 Z19 ] ok
[10:05:53] [ G0 Z10 ] ok

 

Thank you for the quick support.

 

Thanks Peter. I assume more than just @Batcrave and I missed the ease of just putting in the touch plate thickness.

 

Just installed v1.0.215 and tested probe it is working now as it should. Thank you for the support.

 

Like the new Probe routine, especially the auto retract. Looks good too.

Thanks again for the fast responce.