so i have got a problem programming micro:bit. I code it in internet page, then download the hex file and transfer it into the micro:bit. On the internet simulator everything works. Apparently when i transfer it to micro:bit code is not working. The code is really simple, it looks something like this.
animation repeats while variable is 0 (this part works perfectly)
A button makes the variable 1, B makes it 2 (this part works)
when variable is not 0, it breaks first animation loop. (this part also works)
then goes to second loop which repeats while variable is NOT 0 (it will never be a 0 because there is no button which makes variable 0) so it repeats for ever (this works)
in second loop, there are 2 more loops. First repeats when the variable is 1, second when the variable is 2. That makes me able to switch between these 2 loops any time i want. (Problem appears here: i am in loop 2 for example, i cant switch to first loop and otherwise.)
All these errors occurs in micro:bit robot, when code is transferred. In internet simulator code works perfectly. Is it possible to do that code in micro:bit, have i reached limit? Or is robot defective? Thanks for answers and inform me if something is not clear.
This is of course very hard to debug without seeing any blocks/code as I don't know how you are detecting the buttons being pressed when in the second loop.
However, this may be a scheduling issue due to the way you are changing the variable upon a button being pressed. Perhaps consider restructuring your blocks such that they are more event driven, utilising blocks such as on button A Pressed a bit better, infinite while loops are always best to avoid. Also, maybe consider putting a pause(100) in the while loops.
Hope this helps ;)
Edit:
OP confirmed that the pause(100) worked (see comments of this answer), demonstrating that it was a scheduling problem!
For those who are interested ;)...this is because the CPU is busy executing the while loop and doesn't have time to think about the buttons being pressed. The pause(100) allows the CPU to rest for a bit and not think about the while loop, giving it the time needed to deal with the button press. This is known as Cooperative Scheduling!
You can find out more about Cooperative Scheduling at:
https://www.microbit.co.uk/device/reactive
If your code looks like this, you will never be able to change your state variable. You'll get stuck in one of the inner loops, with no option to change the control variable.:
while (unset):
Animate
Check for button
While (set): // Intend to be stuck in this loop forever
While (one):
Do first
While (two):
Do Second
What you need is to be able to update your state:
...
While (one):
Do First
if (button_b.was_pressed()):
state = two
...
This still isn't perfect, you might want to think about what happens if the buttons are pressed in 'unusual' sequences. The simulator should be identical, but there might be something unusual about the way that button presses are handled and your code that have broken the simulator. If the simulator really is broken, you'll need to share a testcase with the micro:bit team.
Related
I have created two vi's in LabVIEW: one to acquire serial data and another to plot the acquired data on an XY graph.
The second VI gets called when a Value Change event occurs on a button in the first VI. But the problem is that when the second VI is called the first VI suspends its operation, hence the values don't get updated.
Is there any solution for this?
First VI block diagram:
First VI front panel:
Second VI (ALL DATA) block diagram:
Well, you are doing some nasty stuff with global variables. This works but is not considered as good practice. (Have a look at queues and notifiers). Further, I don't see how your data gets written to those variables...
In any case, put your 2nd VI in a separate while-loop and schedule it to about 100ms (that is usually enough to update front panels or to interact with users. I'm not sure if your button-event is the right way to go. That is exactly because, the second VI waits for the callback. Just use a simple button and a true-false case to let the second VI keep running (this should even be the solution if you don't want to move the case to a second VI). Just make sure that you change the mechanics of the button to be a switch because you're checking its value not at infinite speed and you want to ensure that it gets caught every time, you click it;)
You will need to use the VI Server functionality. The exact method has changed over the years, but I believe the current recommended implementation is to use 'Start Asynchronous Call'
There is an example that you can view using the example finder. To open the example finder navigate to Help>Find Examples. Then select the 'Search' tab and search for 'asynchronous'. Finally select the VI called 'Asynchronous Call and Forget.vi'
There are other variations for asynchronous implementations, but this is probably a good place to start.
I'm new on this, sorry for bad usage of terms or overextending an explanation. I'm learning code languages and way i found to bring it to my world so i can learn it better, was coding for/with games i play.
When a window close on the game a function needs to be called, when the character move or you pick an item, everything has a command, function, process or some value of an address change and etc... What i wanted to know is if there something that shows me on real time every call, every value change, address value change, etc...
Nowdays i have to reach some value address by CheatEngine, changing the value till i find the correct address. With this kind of thing i would have a list off things that is happening right now, and a "log" of the past things, then i go to the exact time that i did something, so i would have to look on that peace of the list and discover what did my "something"
Click on a button;
Check on the real-time thing what happened at the time of the "Click
on a button" process;
Discover what call was responsible for that and what it did;
Now i can code something that do what "Click on a button" do, without needing to actually click on that button;
I have seen it somewhere, thats why i'm asking here, if i'm totally wrong and this doesn't exist, i'm sorry, i will delete this post.
I believe a Debugger is what your looking for.
The Debugger in Visual Studio does exactly what your describing, you can see the real time values of your variables and objects at any stage in your program.
You can set 'Break Points' that will halt your code wherever you put them, allowing you to inspect your variables.
You can also 'Step' through your code, which will go line by line through your code, stopping at each line to allow you to inspect.
Here is a good page for an overview of debugging in Visual Studio 2017:
https://msdn.microsoft.com/en-us/library/y740d9d3.aspx
I´d like to know how can I stop execution in smalltalk. I entered an infinite loop and don´t want to loose the code that´s written. I tried using pause button but doesn´t seem to be right.
Normally, even if you are unable to stop execution, you should be able to get the code changes you made back from the .changes file. If you can restart the image, there is a 'recover lost changes' menu entry. Always first make a backup copy of the changes and image files before trying this. (In Pharo/Squeak. Other smalltalk have similar possibilities)
it depends on the dialect and possibly keyboard settings.
try CMD-. or CTRL-., which works in most dialects.
If I put the blocks showed in the picture in a while-loop everything fail, fo example the stop button does not working!
Someone could explain to me how use events correctly?
thanks
Also try to avoid coercion dots (small red dots near some blocks like add) the data type is changed dynamically (I32 to double) but it is not efficient and the convention in LabVIEW is to change the data type mostly manually.
You have not connected the timeout terminal.
How it always waits for an event and will not allow you to stop the loop. As it does not iterate, it waits.
To stop the loop you should specify Stop button Event, so your loop will iterate upon clicking on stop and you will be able to stop it. OR you can just specify timeout let say 100 ms and Loop will iterate on timeout case once every 100ms, even there is no event.
The other answers tell you how to patch your code so that your current architecture continues working. But that architecture is fundamentally flawed if your application gets larger -- you're going to waste lots of CPU redrawing needlessly and you're going to end up with lags in your UI. A proper LV separation of business logic from graphics logic would look like the image shown below. This image is a LV clip from LV 2015, meaning if you save the image to disk and then drop it directly onto LV 2015 or later, the code will just drop directly. Sorry, I don't have an earlier version of LV with me at the moment so I can't give you a clip for a previous version, but the code below should work all the way back to LV 6.1 (circa 2001a.d.) if you recode it.
I have been scratching my head trying to find a code that allows the change from on->off to cause something to happen while a change from off-->on not to work.
For example, I have a sensor as an input. At first it senses an object that passes by and rests for a few seconds, so its recording a off (so 0). When it records a off it causes a light to turn on. After the few seconds, the object goes to the end (leaving the sensor) and then comes back and passes through the sensor again. But, I don't want the light to turn on this time.
If the system had a memory that its previous state was off and now its going to sense on, then I wouldn't let a off-->on to work, but a on-->off to work. Is such a code possible on LabVIEW? Are there any other alternatives to this?
I believe this will do it and it's very simple, correct me if I'm wrong because I don't know that I fully understand the logic desired.
The key here is the use of a shift register, it's more straight forward than the local variable option, I'm certain the right solution is there or some small tweak to this.
The shift register is initialized as false and whatever state appears on the output of the loop will reappear on that input on the next loop.
Another interesting solution would be with an event structure to trigger on a value change of "Sensor". This solution can also be slightly more responsive, see below:
You can use a local variable and a feedback node to accomplish this.
Assuming this is in a while loop my solution is to create a local variable hasLit and a feedback node on the sensor input. When the feedback node output is true and the sensor input is false (the object just passed out of the sensor view) we change hasLit to true. The state of the light will then be true if the sensor is true and not hasLit.
Image form