Inventables Community Forum

Probe failure bug

When you followed the link from the firmware flash page to the github repository, did you stay on the master branch and download that, or did you switch to the 1.0c branch and download that?

I followed the instructions to the letter

From the recently updated screenshots I see that it’s the master branch, but as someone who uses git for work on a daily basis the branch to check out should be specified in the instructions. It would have been completely reasonable for someone to think that the 1.0c branch should have been used.

Yes still works. Both x controller and gsheild too.

1 Like

Hi All,

We are really sorry for the issues you have been experiencing with using your Z-Probe. The issue is occurring because an incorrect version of our firmware was pre-loaded on the controller boards, producing an error on how pin states are reported.

To load the correct version of the firmware please follow the steps outlined in this support article.

We will be posting a way to load firmware through Easel shortly. We will give forum users a chance to test this out before we make it available to the wider public. We are hoping to post an update on this sometime tomorrow.

Here at Inventables, we take these kinds of problems seriously. We are investigating the situation to better understand how the incorrect firmware was introduced in the first place, why it was not caught during testing and how we can prevent something like this from happening in the future.

Thank you for your patience and continued support of Inventables. We are thankful to have you as customers, and apologize for the inconveniences we have caused.

Sincerely,

The Inventables Team

3 Likes

I flashed my Xcontroller the other night however, now, looking at the commit history, there is a change to grbl.h which changes the build date but nothing else appears to be touched.

Do I need to reflash? Seems like it’ll just be helpful for error reports/customer service as opposed to functionality but if Easel is looking for a particular build date, I may need to reflash.

1 Like

Reflashing didn’t fix it for me. The setup now works, but when I try to start a carve in Easel I can’t get past the “plug in the probe” step. I’m not using the Inventables probe so I don’t have a socket to plug into - the probe is permanently attached to the X-Controller.

1 Like

@StevePrior if u touch the probe to clip it will show up as plugged.

@PhilJohnson i followed the instructions. Im not good with these little arduino stuff but their directions fixed my issues. Was not that complicated. Especially for someone like u.

You can grab the hex file here: https://github.com/inventables/grbl/releases

Hi Justin,

Easel does not look for a build date.

The results are the same. The difference is that with the Arduino IDE you are compiling grbl right then and there (which produces a .hex file that the IDE then uploads to your arduino). A .hex you download is precompiled so you just need a program that flashes arduinos (theres a bunch out there like XLoader or @paulkaplan 's HexLoader )…

1 Like

It seems to be working now. I power cycled the X-Controller after reflashing it and before I ran machine setup, but I moved right from setup to the test carve and I’ve got a feeling that the controller should be power cycled again after setup, but before you run a test carve. It didn’t work when I went directly from the setup to the test carve, but did work after that when I happened to have re-powered the machine. It’s these edge cases that drive people nuts and cause tech support phone calls.

I did notice that there’s a usability issue with the test probe carve sequence. If the machine has limit switches the user has likely started off by homing the machine, so the bit is at maximum Z. For safety reasons the probing is set to a max of 15mm. If the user follows the instructions exactly and has only moved X and Y before probing the probe will likely fail. Two things should be changed - one is the instructions should be changed to indicate that before probing the Z should be moved to “close” to the top of the touch plate. The other thing that would be nice is to have a “try again, keep going” button if the probe didn’t touch the plate - don’t make the user go back through the entire panel.

1 Like

I understand, but if you follow the directions to the letter you will probably run into the issue, especially newcomers. And sooner or later most people would probably not have moved it close enough and would appreciate the “keep going” button.

2 Likes

Im just hugely relieved that my probe issues have been resolved!!!
THANKS @EricDobroveanu @Zach_Kaplan

1 Like

Apparently the Inventables probe socket closes the connection when the probe isn’t plugged in, so the probe is low when not plugged in, pulled high internally when plugged in but not contacted, then low again when the bit contacts the touch plate.

I’d be concerned about whether the 1.0c that you’re installing is actually for the gShield. The Xcontroller has different pin mappings for the signals so if it’s mapped for the Xcontroller, it won’t work for you.

You’d probably need to change the Inventables code for 1.0c to map for the Gshield as opposed to the Xcontroller.

I can take a stab at reverting the proper file that you can just swap with what you downloaded from Github.

1 Like

The plug is that way as a “fail safe”, it won’t try to probe without a prob connected.

I’d like to see where in the code that is. I only saw different pin mappings for different CPUs, but not for X-Controller vs GRBL board. But maybe I missed it.

1 Like

I don’t think it’s X-Controller specific, it’s more about the plug that comes with the probe. However it did work for me today and I’m not using the Inventables probe and don’t have that normally closed behavior.

It’d be the file revision as opposed to different files. I think it’s the “cpu_mapping” file but I’m not home to check. That is the file that I believe sets up pins and their directions and it could be different between the two. The official release states that 1.0c is for the Xcontroller so if the mapping changed, they wouldn’t necessarily be able to maintain backwards compatibility since I think the same processor is used between them but, again, I could be wrong…unfortunately it’s happened before.