Non code action buttons stop responding after code execution

MakerWorld CyberBrick
1

Heyo, I have here a relic rush board game and there are 5 buttons. 2 of the buttons execute code. When one of the buttons that execute code is pressed the code executes, but then the 3 buttons that do not execute code stop responding until the power is reset. The code buttons however continue to work.

I have tried a factory reset and reloading everything. I have also tried a second set of cyberbrick controllers. The firmware’s confirmed to match as well.

Anyone have some suggestions? The maker said his code works fine for him, he only had issues when his firmware’s didn’t match. He also said I am not the only person to report the issue.

import random, time
from bbl.servos import Servoscontroller
sc=ServosController() <------------------------The code locks up here.

2

I don’t use the Cyberbrick stuff but do use similar microcontrollers and things that could cause this could be in the programming environment versions and even chip revisions. Library versions can also introduce functionality changes.

I think you run some kind of programming environment to shoot the code down onto the board? If you do, might want to make sure you both have the same version.

I doubt a board revision or chip revision would change things like how code executes, but if they have revision numbers, you could compare those too.

Probably not, but if the code is stored as plain text and you look at it with a more featured editor, invisible characters can get added that the programming environments don’t like. I say probably not because that kind of thing tends to break code hard but is maybe a possibility.

Sorry not more specific and keep in mind some or all of that may not even apply. Maybe someone else has ideas?

3

Hello - I just published a new controller configuration about 15 minutes ago that should fix this issue. Please do let me know if you continue to have issues after installing the updated profile. It’s also important to check the version of firmware your boards are running - I’m testing on version 1.0.3.2.

This following isn’t information that you will need specifically, but I’m posting it in case any other project creators have similar issues or feedback (and for future reference):

When launching this project, I made a key error - at least one of my devices was using old firmware and I was a version behind on my desktop software without realizing it. So, the version that I was testing worked for me but wasn’t working for users with the correct, newer firmware. Then, some of my solutions (written when using the old firmware) caused issues when running on the new firmware. Lesson learned - that was my miss.

As @MZip mentioned code execution, I think that the issue stemmed from a conflict between the scripts that run when a user triggers the “Wall” or “Random” traps vs. how the other traps activate: through direct servo movement configured in the app UI. It seems as though there was some kind of conflict between the script execution process and whatever system process was moving the servos based on a button press.

To solve for this, I tried instantiating different servo controllers, changing how I’m managing the Sleep process, garbage collection and the order of operations for each of the button presses. None of these solved the issue.

I think I’ve arrived a solution - at least I’ve been testing it some time now without experiencing any errors. Essentially, I’ve stopped using the UI-configured servo movement and instead am now using a script to control the movement for each trap. I’ve been running this now for 15-20 minutes (and triggering the traps in every order I can think of) and it’s not appearing to become unresponsive anymore.

5 Likes
4

Can you explain what you mean by ‘trap’?

5

Sure thing - this is specific to this individual project: it is a board game where there are traps on the game board itself. When players press a button on the remote, it will trigger one of these traps on the board.

6

Thank you for the fast response. I decided that I should look to see what you’ve done recently and found the game. VERY extensive!

In any case, this does explain OP’s reference - it was not clear to me what a ‘relic rush’ was… :thinking:

1 Like
7

Nice! Glad you guys got it sorted that quick!

I use the Adafruit microcontroller boards and have a similar kind of situation. The version of CircuitPython they use gets revved occasionally and it can break things if changes are in new versions or the code checks versions. I bet CircuitPython on the boards I use is maybe analogous to the firmware versioning you’re having to deal with.

My solution is to package up everything - the CircuitPython interpreter, my code, and the libraries I used with the code. It all stands alone and it doesn’t matter what the most current interpreter version is.

Not sure if you guys in the Cyberbrick world have that option, though. Maybe you do if you can upgrade and downgrade firmware? If the license allows it, if you distribute the firmware with your code, it could make it easier to avoid mismatches?

8

Yeah, that does sound similar. I’m trying to keep this project so that it’s configurable using the app UI so I might be limited in that regard. I do have one of the Feather boards I’m wanting to try, though!

9

@MaKim has indeed seemingly fixed the issue. I am wondering if a command needs to be executed in the code to return control back to the controller as the unresponsiveness occurs after you initialize the servos controller.

10

Ok I’m glad to hear it! I’ll keep investigating it though just to learn for the future

1 Like
11

Thanks a ton for working hard to get it fixed. I’m glad the problem was Identified. I am very curious as to why the code is doing that myself.

12

It is obvious, it locked up where you said the code should lock up.

It did exactly as asked!

That should fix it.

13

Sorry, I’m new to python and I don’t understand.

14

It was a joke. You added a comment saying it locks up here and I pretended that was an instructor gave it.

15

oh poo lol I thought I was gonna get a lesson.

16

You did, you learnt my jokes are not funny.

2 Likes
17

Oh it’s funny, my brain broken and thought you were being condescending and saying “you did this wrong, now find out how to do it right.”

18

No, you were in good hands with @makim, I reached out to him to say you needed help.

He is a good bloke and a great designer.

19

Thanks and yes indeed, he a cool (and very talented) dude. We were already talking about it on the project page. I know he found a workaround and all but it’s bugging me that it’s behaving this way and I’m still poking around at it to try to figure out why. It should work as far as the API doc is concerned and it did work for him on an older firmware. I can only assume the newest firmware update has a bug, I am missing something (most likely since I’ve barely started weeding through the API docs), or there have been some undocumented api changes.

20

The firmware had too many bugs and the early releases had no way of upgrading the firmware as they broke the original methods and held of fixing that in lieu of the new method in the apps.

I was in the second wave of beta testers. I had a lot of issues with the implementation. It seems both well though to and poorly thought out at the same time. Swapping from WiFi in the beta units to Bluetooth in the release units hurt us beta testers. It was painful. Zero documentation, the current documentation is lacking, particularly around the code elements.

Suggestions of compatible additional hardware that doesn’t exist (buzzers for example).

Too many limitations for my liking. Too few LEDs, those components too fiddly to use fir many, disabled people like me find it particularly difficult.

I hope version two makes a huge leap as it has promise.

I have a few CyberBrick models near completed, I am just struggling with the limitations (plus I have been very ill for almost two months) before I release them. I had Halloween and Christmas CyberBrick models due, illness stopped me.

I want mains based power supply, smaller components, more considered wiring and connectors. We currently deal with 1.0, 1.5, 2.0 & 2.54 depending on what we need to connect and to what. This excludes that stupid LED connector.

Too many limitations on LEDs, I am used to running hundreds with Arduino (this is essentially the same thing).

Why can’t I have LEDs on the remote, why can’t I have sensors on the ‘vehicle’? Why is the vehicle a vehicle rather than the receiver? The term vehicle forced the designers to forgo everything else we could have designed.

I will stop ranting here as it would go on for hours.

Except, the damn one second delay to run any code I write, no good reason for that.

1 Like