In DataAvailble could you use this code and send us pics of the debugger to show the message length and the value of bufferString?
Thanks!
// GET BUFFER RESULTS
Dim s, bufferString As String
While Me.BytesAvailable > 0
s=Me.ReadAll()
bufferString = bufferString + s
Me.Poll
Wend
Dim MsgLength As Integer = LenB(bufferString)
Break // SHOW US DEBUGGER PLEASE
I had to install a xojo version in my client’s server which I don’t like much. As soon as someone there makes a call, I’ll post the screenshot of the debugger…
I’m with Steve K on this. Create a timer that fires every 250ms. Create a text area to capture the results. Create a Serial1 that is 19200-8-N-1. On the timer’s action add something as follows:
// monitor COM port activity
Dim s as String
Do Until Serial1.BytesAvailable = 0
// display all recevied characters from COM port
s=Serial1.ReadAll()
TextArea1.AppendText(s)
Loop
You should get the same screen you showed on the other terminals (I think what you showed in Coolterm, btw, looked right as well).
I’ve got some news :
With the code @Mike Cotrone suggested I got the following results:
At some point the PBX started outputting out data… I got the following 4 bursts.
Burst 1 ; The beginning of the header. First 32 bytes.
https://drive.google.com/open?id=1uG-qo7E6FTH_-qpJh_jvmPpQX1CwT5v8
Burst 2 ( immediately after the first burst) : the second 32 bytes (still the header)
https://drive.google.com/open?id=1sIXm-eKbCJUIM5XuooU91zLsMzzqKs9q
Burst 3 ( some minutes later) : The following 265 bytes (the end of the header and two rows of complete data)
https://drive.google.com/open?id=1S2zI8jEf5zGnfTaQiNRYeUdBjRDPx505
Burst 4 (more miutes later) : The beggining of a new (incomplete) row of data. 32 bytes.
https://drive.google.com/open?id=1UVFXk0mokfdbFEbo1pQe1l43WMaNxVKD
The question would be why in the world the data is sent/received erratically, incomplete or in burst separated by minutes ?
But more important why this happens with Xojo made apps while not with HyperTerminal?
I am now going to try the following
1. Try again but dropping the incoming data into a TextArea and removing the break/breakpoint to make sure the inconsitency has nothing to do with that. <<-- Confirmed, removing breakpoints did not improve or change much.
2. Try Langue’s suggestion
3. Drastically abandon the project in xojo and build it in VB6.
Note : I could live with this situation (messages cut erratically, sent in bursts separated by minutes) BUT there are cases where I need this information right away, I can’t wait until the next burst comes in to complete the lacking data.
Thanks for staying with me.
R
This morning I woke up, and looked at the little test project I made last night following Langue’s suggestion.
There was no data. nada. nothing.
I closed and Immediately after that I run HyperTerminal and all the data that Xojo app had not received got in (probably was in the buffer ?).
https://drive.google.com/file/d/1vWMWQHw_T65tU9CJj9OGSehTsvbeJFW5/view?usp=sharing
What a frustration and waste of time. At this point I am thinking there is something with the Xojo serial mechanics that doesn’t work in my particular scenario.
I need to find an alternative. VB6 might do, but I am using CubeSQL, so I wouldn’t know how to get the data in the DB…
sigh…
R
@Roman Varas - So for every buffer line you want to keep as a “whole” string chuck it ends in CRLF (0D0A).
What if we just loop until we see the 0D0A - I am not sure if you had tried this yet - I mocked up your data to test the string matching.
// GET BUFFER RESULTS
Dim s, bufferString As String
dim EOF as String = Chr(13)+Chr(10) // 0D0A
Dim lastByte as String
do
Me.Poll
s=Me.ReadAll()
bufferString = bufferString + s
// CHECK FOR EOF
lastByte = right(bufferString,2)
Loop until lastByte = EOF
I’m wondering if perhaps &H0A is actually the start of data & &H0D is the terminator. I have seen this before last century where the serial printer would perform a carriage return, then line feed & print the next line when more data was received, this allowed the printer to underline or bold the output to highlight the current message.
while this reply will not do anything to get you to write your code correctly, it is just to say i am using Xojo to write almost exclusively serial based projects for several years.
i develop on a MAC, largely the applications (which are all industrial control and science based) are deployed on win pc, and in the last 2 years a LOT of raspberry Pi.
all of them use exactly the same serial based container i wrote, and it is based on the serial sample in the examples folder.
my method is very simple, i have a timer that is started inside the data available event, there is a buffer that copies the data in the serial buffer, and when the next data available even fires it appends the data to the existing buffer.
providing the timer has not run out.
the timer is used to create the end of file period, if the data received is not valid when compare to my expectations (such as having a control character as the last byte) it is dumped as bad.
the timer period i use is 20ms, which is set because i know all the data from the hardware (which i also design and code) will always get sent in that period.
it is really simple, there are no tricks to getting the serial port to work, it is as straight forward as any peripheral could ever be to use and i claim nothing in originality in its method on all platforms.
it is totally reliable and i have only seen a couple of times in several years when the corrupt checking code has fired, and never had it reported by a user.
with all this in mind i am really surprised that you are seeing such issues, the code i use is really nothing special in any way, keep looking into it and i am sure the penny will drop in no time.
do you know if the data sent is in a continuous stream or is it sent in separate chunks with a period of time between the elements?
@Roman Varas
Just like Mark C I almost develop all apps to work with serial port, be it Arduino-based, ARM-based, Microchip-based, plus many eval systems to work with ADI and TI eval boards, and several test equipment. We use Windows exclusively where I work at so that is the platform I use the most. Just like Mark C I have yet to run into a serial port I can’t use Xojo with.
Following are several very basic example projects I’ve shared in the past:
Basic Serial Monitor using DataAvailable event
Basic Serial Monitor using DataAvailable event and Serial polling with Timer
Basic Serial Monitor using Timer
Following is a better example that allows selection of baud rate and logging to file. Also a compiled application is included in case you are fighting some weird bug on the version you are using:
Better Serial Monitor
Compiled Application
One caveat I do remember from a somewhat distant past. Xojo did show some low-level serial port issues when using USB-serial converters with Prolific drivers. But I don’t recall seeing that in any recent times. But the only way I would think the above programs do not show any traffic on your system is that either you have the wrong serial settings (but you showed a screenshot with hyperterm settings and coolterm settings with valid data; so I don’t see that possible), or you have some Prolific hardware/driver which is manifesting the old low-level driver issue with Xojo. Really hope the examples above prove useful.
not seen it mentioned in this thread(sorry if it has been), but cool term is written in Xojo as i expect everyone knows, so if that app shows the full message it might further suggest that Xojo at its core is not the issue, rather the implementation?
Thanks everybody… you guys are great. I will (try to) get to the bottom of it.
@LangueR
The system in question DOES have a Prolific USB-to-Serial comm port adapter… (driver ver 3.3.2.102). So we might be onto something there.
Serial term also shown problems (although the data was received -partially- and in somehow erratic chunks)
[quote]This morning I woke up, and looked at the little test project I made last night following Langue’s suggestion.
There was no data. nada. nothing.
I closed and Immediately after that I run HyperTerminal and all the data that Xojo app had not received got in (probably was in the buffer ?).[/quote]
That sounds a lot like a hardware flow control problem (RTS/CTS or DTR/DSR). When hardware flow control is used the device will not send the data until it sees that the clear to send line is high. Try turning on CTS flow control as well as turning on DTR. You may need one or both of those.
I like what Richard is saying. Flow control i[/i] is a must for some devices.
Regarding the usb to serial adapter, that may be an issue as well. I guess you could always try it on an older computer that has a real physical RS232 port and therefore eliminate that as the problem (easy for me to say).
I had a bit of spare time at work today (don’t tell the boss :)) to read up on the PABX/PBX system and from what I gathered, the data is delivered in chunks, and therefore requires some sort of handshaking to determine the beginning and end of it, and when to receive/send the data.
The fact that HyperTerminal/RealTerm showed and received data is perhaps by happenstance. I mean, those programs would have auto functions that look for a valid connection by throwing out various handshaking codes (questions):
ie. Are you there?.. Yes!, I’m here… Fine, send me the data… Not a problem, here it is… Hang on, hang on, I don’t think I got all that… Well, how would you know what you got, unless I told you?.. anyway, that’s your problem… Hang on a sec, I didn’t know but I’ve heard about CTS, DTR/RTS, XON/XOFF, but who the hell do you think you are?.. Oh shutup!!.. No, You shutup!!,… yes I will… and so will I . . . . . .
None of that would account for “packages” or “chunks”, and therefore you would receive some data, but not all of it, as you have already described above.
Therefore in Xojo you have to build in the correct functions yourself, ie. customise the code to suit your particular needs. Although Xojo seems like “higher” level programming, you can also access lower level functions if you need to. Far beyond my level of understanding, but they are there :).
I’m positive you’ll sort it out - and we’ll all learn something too.
Hey everybody
I would like to tell you guys something I noticed that might be relevant.
At this point I discarded a code issue. I tried every possible code tip, combination, xojo made app, and example given. This is not about how the data is handled once in Xojo, it’s a lower level issue. Data is being input erratically with every xojo app I tried. Sometimes data does not even get to the port, sometimes it arrives in pieces, sometimes gets there complete. So
as some of you suggested, I agree it probably IS a low level issue. (please, read on)
Taking a look at the server where all this is going on, I noticed the the Prolific USB-to-Serial driver was from 2008, so I tried to update it and noticed that windows failed to activate it (once updated). That is : a yellow exclamation mark next to the driver in device manager. Further reading in google led me to think the hardware adapter it’s either an old model or has not an original prolific chip.
So now… I am stuck. Xojo seems to have issues in its Serial implementation. (At least two of them acknowledged in private by Julian). (thanks a lot, by the way for letting me know) and also I have now an OS-Hardware situation.
The only thing remaining for me is to sign up for a Xojo pre release which has apparently fixed one (or both) of the Serial related issues, and with that installed on my laptop, go ON SITE, with a USB-SERIAL adapter I have which works ok with the latest driver, sit next to the PXB, plug the cable, and make some phone calls, and start some (time consuming) trial and error tests.
I don’t have such time resources to do that now, and also I don’t like how it will look like in front of my client.
STILL HyperTerminal gets all the data, that’s what get me upset…
Anyway… I will let you know whatever I do or find out.
Once more, I appreciate a lot all the help from the forum members.
Roman
You may be SOL, but the link below talks about an intermediate driver that that may have corrected the “buffer flushing” issue. And you can see how some terminal programs worked correctly and some other ones didn’t (not just Xojo).
http://support.plugable.com/plugable/topics/serial_port_adapter_occasionally_does_not_flush_buffered_characters
As aside, did you try the compiled application with 2014, just to make sure you were not fighting a Xojo regression (assuming you are working on 2017/2018).
@LangueR : I am leaning towards this hypothesis. It’s a driver problem. BUT, until I go on site with another (new version) of the adapter which supports the latest driver and switch it I have no way confirm this. Yesterday I saw this same issue with another terminal app that was NOT xojo made. So what I am seeing here looks a lot like the symptoms people exposed on the link you posted.
Next step is checking compiled app with xojo 2014 AND updating drivers on the server.
By the way… what does it mean “You may be SOL” ?
Thanks, Langue.
SOL - sh#t out of luck
I have 3 Prolific adapters, various ages and versions. None of them are reliable on Windows.
They work fine on Linux, even on a Raspberry Pi.
If you must use windows, try a FTDI chipset adapter like this one:
USB to RS232 Adapter with FTDI Chipset
For what is worth - I use this EasySync USB to Serial Converter in the XOJO serial apps I’ve written and it works flawlessly. It utilizes an FTDI chipset like John suggests as well.
and I always thought it meant sort of lost.