I’m joining a few others here and reverting back to 1.1.2.a. I upgraded (sic) to 1.2.1, my screen image has been sat on by an elephant, I’ve lost about 1/3 of my screen real estate. I cannot say if any of the other issues are present, I’m not going to ever try to work from a screen like that.
Eric
1 Like
Was your screen powered on before you started the controller? That happens to me when I don’t have the screen plugged into an actual power source.
2 Likes
Will you be posting a detailed, narrated video of your first issue so we can see if the devs can fix it?
Ironically, for your second issue, see the post right above your post.
2 Likes
- is your screen powered by wall power?
- did you turn on the screen 10 seconds before turning on the controller?
while xyz probing, after touching the bit to the touch probe and hit NEXT, it just sat there. Canceled and tried again, no change.
This happened to me today too. I was able to recover without rebooting by using the software estop button then re homing. After that xyz probing worked again.
Edit: I read the other post explaining this is due to the code buffer chip after pausing or stopping. That is when it happens to me too…
Otherwise firmware is working great!
1 Like
Yes, my screen is always powered on, has always been powered on since v 1.0.9 with no issues what so ever.
1 Like
Yes, my monitor is wall powered, and it has stayed on since v 1.0.9 with no issues what so ever. I even tried turning it off and back on right before booting the controller… NO GO… still missing the top and bottom of the screen.
1 Like
If you’d like this to be fixed in all future firmware, posting a detailed, narrated video of your issue will be the first step.
1 Like
What has happened to you today? Can you post a detailed, narrated video of your issue? We can’t fix what we can’t see or replicate.
1 Like
Thanks. Edited my post to clarify it was about a freeze during xyz touch probing after the continuity test. I had to cancel probing and software estop/home then probing worked as expected. I’ve since read the other post you linked explaining it’s a hardware buffer implemention limitation that can occur after pausing or stopping. That’s consistent with my case. Thanks for the background.
I can appreciate the difficulty in troubleshooting without a reproduceable case. I’m sure it’s hard to stop my gcode at the exact same moment, jog with the joypad into position to xyz probe a second time to reproduce it on video. Fortunately and unfortunately it usually works as expected when I retry 
2 Likes
Is anyone having an issue getting the controller to work after updating to 1.2.1?
I have formatted the SD card using SDFormatter (full overwrite) and tried flashed 1.2.1 twice now. I still can’t get the controller to change speeds or control the X-Axis.
Any ideas?
2 Likes
If you mean joypad, ensure it’s one purchased from us, and see:
Yes I mean the joypad. It worked perfectly fine immediately before flashing new firmware.
Is it:
- purchased from us?
- in the right mode?
2 Likes
- Yes. Wired model
- Yes.
I have also tried a Logitech generic controller that I was using previous to purchasing Onefinity controller that worked well and was able to move all axes and change speed (replaced due to it being dropped and cracked, but still worked). It is also doing the same thing now.
1 Like
Is there a place where the development backlog is visible or where certain features are upvoted?
1 Like
I bought one of these
Amazon.com as far as 1f knows it’s on a wired network. IMHO 1f should start including/selling wireless access points and get out of the wifi business altogether as it’s a no-win scenario. If it works … great my machine connects to wifi what next … if it doesn’t then it’s why doesn’t this POS work.
2 Likes
Post a video of this issue so the devs can take a look.
1 Like
A little clarification please. So if I got the firmware upgrade notice on my Buildbotics controller and performed the upgrade, I do not have to open the controller and reflash the SD Card, or ?
I’m assuming (hoping) that the firmware upgrade notice would only be on the controller if it was okay to proceed; especially since there was never any communication cautioning about needing to reflash the SD card prior to or after this firmware update.
Please confirm.
Tom
1 Like
Hey Tom,
But, with 1.1.1 you had to, unfortunately. 1.1.1 was buggy, but could not be downgraded.
That’s what usually users should expect, however, this was not the case a short time ago with 1.1.1.
Usually it is never necessary to overwrite (re-flash) a Raspberry Pi OS installation (except if the SD card fails). Today, all Unixoid Operating Systems have smart package management systems. Usually unixoid operating systems have an uptime of monthes, even years, and are updated while they run – including occasionally necessary downgrade of a package.
But the ‘onefinity-firmware’ package is the only package on the Raspberry Pi system inside the Onefinity Controller that is not packed as ‘.deb’ package and therefore cannot simply be downgraded with ‘apt-get install onefinity-firmware=1.0.9’.
1 Like