Some of the projects I like to do involve controlling motors and steppers, usually via Aduinos or PIC controllers. It would be nice to be able to be able to respond to an open comm port to similar to : bmpbutton #main.button1,..............,[buttonClick1] ' ' wait
[buttonClick1] handle the button click
Like: Open "com14:9600......." as # openedUSB OnCom #openedUSB, data.available [inputDataHandler] ' ' wait
[inputDataHandler] code to process the input
I know you have a lot on your plate. Just a thought. Charley
In the projects I'd be concerned with, I have a set menu of responses from the controllers (Arduinos and/or PICs) that I would be expecting so manipulating the received data is not that big a thing. As with the current LB instructions for receiving data, you pretty much have to have an idea of the form or structure (ie. CSV, Binary numbers, etc.) to make sense of what's coming in. So I don't think there would be any difference here. What I see as an advantage is that the program is not stuck in a loop waiting for a serial port to respond. Charley
Post by Brandon Parker on May 4, 2020 7:56:52 GMT -5
Charley, You would not stay in a loop waiting for the COM Port. You check it to see if you have data and/or sufficient data and take care of it if you do; otherwise, you simply go back out of the loop and do other stuff until time to check again. As Rod might be hinting at if the OnCom event that you are suggesting fires every time the COM buffer is changed you will be checking the buffer often anyway. Most of the time it is sufficient to just check the buffer "often" either via the timer of a processing loop. I do the latter because the Timer in LB has issues with Subs/Functions and scoping, and I always use Subs/Functions.
I thought I posted this yesterday, but I actually didn't hit the button.
Here is a little bit of code that you can call to retrieve COM buffer data up to a delimiter. Notice that I define True & False to 1 & 0, but you can use hard-coded values or change things if you wish. Global False : False = 0 Global True : True = 1
controlCharacter$ = "##"
Print receiveMSG$(controlCharacter$) Wait
Function receiveMSG$(controlCharacter$) If LOF(#COM) Then comData$ = Input$(#COM, LOF(#COM)) If (Instr(comData$, controlCharacter$) > False) Then receiveMSG$ = Trim$(Left$(comData$, (Instr(comData$, controlCharacter$) - 1))) End If End If End Function
I think you miss the main point that the oncom event would need to know when a complete message, not a partial message or a single character of a message, is passed. So you would have three ports all firing events that are of no real value. The only event of value is when a complete message has been passed.
So how do we know a complete message has been passed? From my understanding the port does not support such an event so neither could Liberty.