OnComm#openedUSB [inputDataHandeler]

[charley]

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
  
  

[Rod]

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]

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

[Rod]

So this OnCom event fires every time the buffer changes?



alycesrestaurant.com/lbpe/AccessingSerialPort.html

[Brandon Parker]

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]

With two or more com ports open, wouldn't an OnCom#hnld,[dataHandle] instruction be much simpler?
Charley

[Rod]

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]

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

[Rod]

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.