Ok, I’m sure this has been discussed before.
In the app/cloud side of things, all the transactions are pushed and received by the ‘app’ with the blynk servers in near-real-time, and transmitted to the ‘receiving device’ when it’s available.
It’s painful to combine blynk with any ‘real-time’ controllers, because any calls to blynk that ‘send’ values to the app - are blocking functions - waiting for the network.
Is there a plan to asynchronously queue these outgoing messages in the blynk library code so that local ‘foreground’ tasks can continue…?
Perhaps an extra parameter that indicates when it’s a non-blocking request, and a returned value provides a queue message number or similar for referencing that message.
Then if it takes too long for any reason, a ‘delete message’ request etc could remove the offending item from the outbound queue, or if non critical, it can just go whenever it can.
Blynk.virtualWrite() commands just send their data to the server, and if it is not there, into oblivion… without waiting for any feedback.
Using Blynk.begin() can cause blocking problems if no server connection is made, but Blynk.config() will not.
This is because people try to combine Blynk IoT code with “old” arduino coding style, that relies on dumping everything into the void loop() to run thousands of times a second… but then toss in delay() commands that stop all processing when needed. Much like racing ahead then screeching to a stop in rush hour traffic… Bad coding for new IoT processing.
Much better to do proper timing and “merging” to maintain proper consistent flow.
Thanks @Gunner, Sorry, i probably didn’t phrase my observation well.
Say - for example I have a 500Hz timer running in the background that executes ~50uS of code - every two milliseconds.
If I set…() a property between timer ticks, the timer events are ‘stalled’ for several milliseconds until the set…() call returns.
i’d have hoped it was microseconds rather than milliseconds.
Whatever you are trying to do with such precise timing MUST coincide with Blynk’s internal timing for controlling BlynkTimer and Server connection & communication housekeeping. Blynk has a timeout heartbeat just for such blockages, but so must your code be accounting for shared processor “time”
This is NOT a Blynk specific issue… Any and all IoT or communication type libraries that are in constant communication with the rest of the internet must share the limited processing, on simple MCU’s like Arduino or ESP, of time sensitive activities wanting action at the “same time”.
If you want truer multitasking then look at running a Python or NodeJS based Blynk client, or two or three, on something like a RPi
So, I’m guessing that using Blynk in stepper motor control and other similar applications is a no-go?
That’s a bit sad - because my project is very simple
a button to run toward target #1, and another to run back to target #2
The motor’s currentPosition is compared to the targetPosition, and the 50Hz timer events tick(step) toward equilibrium between the two.
But you’re saying the background Blynk functionality won’t let that occur smoothly if a set…() is issued during normal program execution.
If I perform a Blynk.set…() at any time while the motor is running, I get blocking until the set() returns - and those intermediate timer events (steps) are missed.
The motor/counte still gets there - but with a few jerks & bumps on the way.
Oh well - it looks like we’re going back to a self-coded web-interface.
Not at all the case… Everything is possible, but it takes some tweaking and you may lose some degree of really fast Stepper control.
Or even dual MCU control… Blynk on an ESP (or Arduino I guess) for the UI and an Arduino or ESP for the Stepper code… this way the only other “timing” issue you have to share with the Stepper code is the cross MCU link via i2c or Serial.
Yep, got it thanks.
As you may have seen previously, I’m not using stepper.h or any library - just hard coded bit-bashing in the timer event. (Cleaned up a bit since I last posted)
I’m thinknig the two processor mnodel may be the best way to go with an Arduino doing the motor control and ESP for the Blynk interface.
The guy I’m helping will be a little discouraged - but at $5 a piece on eBay a UNO or other is the least of his worries. Maybe a custom PCB with a 328 on board.