charley
New Member
LB User since 4.3
Posts: 8
|
Post by charley on May 1, 2020 11:34:56 GMT -5
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
|
|
|
Post by Rod on May 1, 2020 13:25:47 GMT -5
Sounds like a good idea. But, there is always a but, the com port streams data. So the data may only be some of what you want or two or more of what you want. How to know you have a single data item?
|
|
charley
New Member
LB User since 4.3
Posts: 8
|
Post by charley on May 3, 2020 13:10:10 GMT -5
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 Rod on May 3, 2020 14:16:44 GMT -5
|
|
|
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
{:0)
Brandon Parker
|
|
charley
New Member
LB User since 4.3
Posts: 8
|
Post by charley on May 4, 2020 13:30:07 GMT -5
With two or more com ports open, wouldn't an OnCom#hnld,[dataHandle] instruction be much simpler? Charley
|
|
|
Post by Rod on May 4, 2020 14:06:50 GMT -5
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.
|
|
charley
New Member
LB User since 4.3
Posts: 8
|
Post by charley on May 5, 2020 11:37:12 GMT -5
This is not an original idea with me although I seen it used before in VB 6 professional edition. I don't remember the syntax but it was some thing like comEvent. Charley
|
|
|
Post by Rod on May 5, 2020 12:15:21 GMT -5
If you can find more detail on that great. But watch the difference between a com object in VB and a serial com port on Liberty they are two different things.
|
|