Hello, I am looking for someone that can create an extension that can mimic the behaviour of something like object.wait where the block would stop and wait X amount of time before continuing to execute the sequence of blocks.
Basic example of usage
Call BT Send Text xxxxxxxx
wait.50ms
Call BT Send Text xxxxxxxxx
Yes, this could be done with a clock, evaluate but ignore and a procedure with return valve but it ends up using more blocks then I can afford to spare.
I’d like a couple of blocks with preset amounts of time and one block I can set a time value for.
Examples of what desired basic blocks would look like
These blocks would be more of a WISH LIST in addition to the above blocks
This block would act as a pass though that just waits X amount of time before the value is passed to a block like a variable.
The only requirement is the blocks can NOT block the UI while it’s in the wait period. Doing this with a clock is non-blocking and that is exactly how the block should work.
Name your price…I’m willing to pay well for this.
My desired time frame would be last week lol, I need something ASAP.
I am using Kodular so I’m not worried about compatibility with other block builders.
You can PM me with offers or post them here, I really don’t care either way.
I no longer need these made, I was able to use the Appybuilder Extension IDE and create this myself with the help from a friend.
This is what the code I used in the IDE looks like, I used the tinyDB example and just altered the code for the blocks. I’m sure its not perfect but it does exactly what I need it to do. When using it in live development the times were slightly longer then they should be but when the app is built the times are exactly what they should be when testing on 2 very different types of Android phones(Pixel 3 VS S6). Device speed had no impact on the delay times.
//********************************** End Use DataInput + Use TimeInput Delay Blocks @SimpleFunction(description = “Delays passing the data input for X amount of time. This is a blocking function”)
public Object DelayPass( int TimeOut, Object DataToPass ) {
//********************************** End Use DataInput + Use TimeInput Delay Blocks
//********************************** Start No DataInput + Use TimeInput Delay Blocks @SimpleFunction(description = “Delays for x time, this is a blocking function”)
public void Delay(int TimeOut) {
try {
TimeUnit.MILLISECONDS.sleep(TimeOut);
}
catch (InterruptedException e) {
}
}
//********************************** End No DataInput + Use TimeInput Delay Blocks
I have a very unique app, it is used to read and write the binary file stored on an eeprom chip inside in the engine control(ECM) modules used in late model General Motors vehicles over BT to an OBD II device(like an Elm327).
Due to several factors, some being due to the BlueTooth tools that’s used and others are due to the nature of how the ECM flash routines work it is necessary to pause briefly between messages that are being sent to the vehicle. Most of the flash routine is executed based on a send 1 message get 1 message back from the computer basis but there are a couple of places that need an actual delay added between messages that are being transmitted.
The example that Taifun linked to for the Please wait method only works when your not executing a continuous sequence of blocks. The point where the example creates the delay by calling the procedure is not in the same place where the delay occurs. In a simple example it can be made to work but in my situation it would quickly make things vary hard to follow. Until recently I have been able to work around the minimal amount of time that was necessary between messages being sent however since I have just released my own tool for use this app I can no longer work around the delays in the same manner. The tool I created is able to alter the speed of the computers data bus in the vehicle so it’s running 4x faster then normal. The advantage to this is is greatly reduces the amount of time the flash procedure takes, however the faster speed has made dealing with the timing between messages much harder due to the increased speed.
Below are 2 examples that both do the same thing just in different ways but in both cases they still need a brief pause between them. The data that is typically sent is much larger then whats shown in these blocks, this was done just for an example. Normally each BlueTooth block is sending or receiving between 12 and 8,200 characters. When sending LARGE messages over BT it takes time for the actual transmission to take place since this is being down wirelessly and is the reason I need to delay sending between messages.
Here is short video demonstrating the app sending mid sized blocks(about 4200 characters) during an ECU flash where it is also switching between these mid size data blocks and much smaller messages that use RLE compression to write preconfigured messages into the ECU that are triggered by these shorter messages in the flash kernel being used to control the flash routine. ECU Being Flashed with RLE Compression
If you are at all intrigued or interested in what something like this might look like here is another short video that shows snippets of some of the blocks while the app is demonstrating another computer flash. ECU Being Flashed showing snippets of blocks used
I have been working on this app for more then 3 years now and spoken with Dozens of professionals in that time who write C#,C++ or Java for a living and it took nearly two years to convince them that what I was working would actually work, and that it could be made reliable. More then a year ago every one who doubted my work(or that a block based programming language would be capable of this) conceded that not only did this work but it turned out to be faster and more reliable then similar programs written in C# that where using USB devices to do the same thing. People are still shocked I was able to make BlueTooth reliable for something like this and that it was done with the equivalent of Lego’s.
So…my need for delay blocks are a bit different than what you might suspect your average person would do with them
well… not really…
for a few milliseconds it’s fine… but you will get problems, if you try this for some seconds…
you could have done this using a few existing blocks, too…
