Communications example not working in Mojave

I am new to Xojo and so I always try the examples first to help get an idea of how the software functions. I am particularly interested in building apps on the Mac to communicate with vintage test equipment which mostly use serial comms so the first app I tried was the Serial Port Bar Code Reader example as this is a basic way to see if there is comms between the HP34401A and the Mac.
Unfortunately I could get nothing back that made any sense, in that it would never see the CRLF even though they were present in the data stream. I checked the obvious such as baud rate, etc. and even ran a terminal program to check that there were no external problems. The HP was sending simple data at 9600,n,8,1 with no handshaking. and terminating each line with a CRLF as required. I checked the Serial Controller object and ensured that it too was set to 9600,n,8,1 with no handshake.
Before updating Xojo to the latest version (2019 R1) the program would run when pressing the Connect button but would never return any data. However since updating it now just gives the spinning ball of death and I have to force quit it along with Xojo.
Has anyone else seen this problem when running MacOS Mojave or any Mac OS?

Thanks

Is the example from 2019r1 (or older) ?

If older, try the version from 2019r1.

I have tried both versions of the example in both versions of the program. With the previous release of Xojo the example didn’t crash but also didn’t work. In the latest release 2019R1 it simply freezes and requires a force quit.

I have tried to debug this app but the method of coding they use really sucks. Coming from an environment where all of the code was available such as with Visual Studio or Eclipse or even the Arduino IDE I find it almost impossible to deduce the flow of code in this disjointed way of doing things. What is the sequence of constructors? How is an event handler associated with the event? Simple stuff which helps you debug. That is unless I am missing a trick and it is possible to see all of the code at once.

I put a break-point on the Data Available method of the SerialController and it steps through ok but when pressing run at the end of the code it hangs. I have no idea where it goes after that. Is there a constructor somewhere? Who knows.

I’m pretty sure that this used to be Real Basic in a previous life and I seem to remember that it had the exact same problem when it came to following the flow of the code.

Don’t click Run, instead use Next or Step Out to see what the next code line is.

OK the reason for the hang is that the PortListUpdater->Action method is being called repeatedly and constantly. This would appear to be something that was introduced by either the update to 2019R1 or a change in Mojave. Not sure why the PortList Updater needs to be fired so frequently.

Having sorted that issue I am still unable to get the serial data. The SerialController->DataAvailable method is being called just once at the start but even though there is data incoming and the data does have the requisite characteristics the data buffer appears to be either empty of has some garbage in it. Adding the code i=SerialController.BytesAvailable in the DataAvailable method shows 0 bytes actually available.

What Mode do you have the Shell set to (0, 1, or 2)?

Sorry but I’m new to Xojo. What is Shell mode?

OK, i’ve found the reference but I’m not sure what the default is.

Seems that Shell.mode is for command line type applications unless I’m misreading it

Changing the Shell mode seems to have no noticeable effect unfortunately.

Out of interest are there any Mac users out there that have been able to run the Serial Port Barcode Reader application? If so what MacOS are you running?

Man,I don’t like that example code at all. This is what I use in multiple projects and it works well on Mac and Windows. This is in the DataAvailable event:

[code]Dim s As String
While Me.BytesAvailable > 0 //Me is the serial class
s = s + Me.ReadAll //add whatever is new to our string.

Me.Poll //Keep polling until BytesAvailable is zero
Wend

//process string.
//Look for termination characters.[/code]

Thanks Bob. Slightly better in that it returns one character and then the DataAvailable method isn’t called again.
This is an example of the data being sent -
1.08481000E-04

but the single character is usually something like E6 or BD. Nothing really like anything being sent.

The shell was a red herring on my part, sorry. I do my serial I/O via a shell helper that I wrote in C for consistency on all three platforms back in the RS 2006 days …

If you connect to the Barcode reader with a plain terminal program, do you get the value as a string?

Hi Chris,
I use serial in a project that has been in development for a number of years and it is operating on Mac, Pi and windows.
it is perfectly reliable and never misses a beat since the first time the code was written, it is extremely simple I have found.
I operate with 57600 baud, 8 N 1 without handshake.

my method relies on the hardware system I have sending data at a period (100ms) longer than the timer (20ms) used as the END of data packet signifier rather than looking for an end character in a random packet of data.
This method may not be as useful in some applications but It is very good as a start point and will work perfectly in the application you outline.

in the serial port ‘DataAvailable’ event:-


RXTimer(true)//start the RX data 20ms timer every time new data is seen, this is a single shot timer in MODE 'single' with a PERIOD of 20ms.

RxData=RxData+me.ReadAll()//load the received data int0 the app property 

in the timer ‘Action’ event:-

if Len(RXData)>0 then
//do something with the data received, call a method that works on the data, do not handle the data here.

RXData=""//clear the property here so the next data packet can be created
end

That is basically all there is to the serial port part of the code, I do have a flag in my code that blocks the new data coming in until the current one has been serviced but thats not included here.

Also I am ONLY communicating in my system using ASCII therefore I will only ever need to work with UTF8 characters in the decimal range of 32 to 126.
As you have a line feed you will need to check the data for either a decimal 10 or 13, I use ‘ascb(some single data character)’ to convert the received data characters one by one to decimal values and if they are 10 or 13 I know its an EndOfLine (in my case).

A final thing is you mention the expected received data, depending on how you are viewing the data it may or may not make sense.

1.08481000E-04

In a HEX viewer it would be:-
31 2e 30 38 34 38 31 30 30 30 45 2d 30 34
at the end of the data you would have either 0a or 0d whichever is used as line feed.

Sorry if that is already known to you, but it is so easy to forget that data seen in the terminal application text field is not the raw data but the ASCII representation (usually) of that data, plus if you load the received data into a string in the ‘DataAvailable’ event and then print it to screen you will see ASCII characters which is going to confuse if not remembered.

Thanks for the responses everyone.

Tim - that’s OK. I thought it might be something like that. Yes the incoming data from the HP as seen by a simple terminal program is absolutely correct in all aspects. I also used the terminal program that comes with the Arduino IDE and it handles it OK too.

Mark - Thanks for the info, I tried what you suggested and still no luck. I added a Timer object called it RXTimer and set it to 20 and single but the compiler didn’t like RXTimer(true) so I changed that to RXTimer.Enabled=true. Added the rest of the code you suggested and ran it. It called the DataAvailable method once with garbage and never called it again.

The incoming data is as bog-standard as possible and as you inferred it is a stream of hex values which represent the ascii values 1.08481000E-04 for example.

Are you running Mojave? I’m running 10.14.4.

hi Chris,
RXTimer.Enabled=true is correct, I use a method to start the timer as it sets flags for other things not required in your case.

I am not using Mojave, 10.13.6 High Sierra is the latest I am daring to have on my development system.
the method I described is completely ok on 10.6.8 to 10.13.6, windows from 7 to 10, Linux Mint 17.3, and all versions of raspberry Pi I have come across.

I do have a Mojave partition on my iMac so I will see if I can get my code working on there, that may not be this day but by tomorrow evening, if that helps.
I will try this for myself too as it will be good to know for future readers.

Thanks Mark, that would be great. I can’t think what else it could be other than the OS version if you are having it work OK so I look forward to seeing your results.

I tried my serial application in a brand new Mojave installation.
I have 3 USB to RS232 converters and a USB to RS485 converter, 3 of these are FTDI and one is Prolific chipset.

Without any modifications, startup warnings or any intervention to the code I ran my serial application and it immediately detected the FTDI based serial converters, received and transmitted data at 57600 8 N 1 and decoded the test packets I use for fault finding with 100% accuracy.

I am amazed this is the case as I have completely avoided Mojave since the start due to expected issues with the serial port, but its absolutely fine.

I have no doubt the Prolific chipset converter will work given the correct driver, which is what I needed for High Sierra when I installed that as my primary OS last month.

Full spec of what I am using:-

iMac 27, 3.4G i7 ,16GB, 3TB Fusion Late 2012
Xojo 2016r3 compiling to 32bit
FTDI based USB to serial converters

If I can make some time I could do a simple one window demo for the serial port that works here, I can not post my existing application as it is for a very specific product which is proprietary.