Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : Programming, I smell a rat
Author | Message | ||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 926 |
I am trying to chase a consistent error in one of my projects. Basically an F4 mite is sending out serial data to a radio unit and waits for a reply from the targeted remote radio unit. If a reply is not received after 5 attempts the mmbasic will raise an alarm code and continue operation. The alarm codes are collected by a VBasic program along with other monitoring tasks and logged to the PC HDD. Here is a selection of error logs over a couple of days. 08/10/2023 13:45:57 081023 130159 Transmission Alarm RTU09 09/10/2023 14:45:51 091023 140159 Transmission Alarm RTU09 09/10/2023 15:45:51 091023 150159 Transmission Alarm RTU09 09/10/2023 17:45:51 091023 170159 Transmission Alarm RTU09 09/10/2023 22:46:00 091023 220210 Transmission Alarm RTU10 10/10/2023 13:45:13 101023 130126 Transmission Alarm RTU10 11/10/2023 15:45:41 111023 150200 Transmission Alarm RTU09 16/10/2023 17:45:16 161023 170200 Transmission Alarm RTU09 17/10/2023 16:45:11 171023 160200 Transmission Alarm RTU09 17/10/2023 17:45:10 171023 170200 Transmission Alarm RTU09 The logs show the PC date & time, the mmbasic date & time and the error created. I am suspicious of coincidences in that these errors are logged when the PC clock is around 45 minutes past the hour but as the mmbasic clock is not synchronized with the PC clock it does not share that time and it is mmbasic that creates the alarm. Does anyone have any thoughts why this would be happening? |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
Typically mysterious problems with the serial interface are the result of not realising that both send and receive are buffered. Your description does not provide enough information but, for example, when you send the serial data to the remote radio unit it will be be buffered and sent out while your program continues. If your program then immediately looks for a response you will receive nothing because the radio unit will still be receiving the data being sent to it. Geoff Geoff Graham - http://geoffg.net |
||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 926 |
Thanks Geoff, I am fairly certain that the RS232 port is functioning ok. Heres the code that handles the send and receive of the radio message. Sub SendMsg For I = 1 To Retry On Error Skip Open "COM1:9600" As #1 'Re-Open port to LoRa Radio Unit Print #1, Msg$ 'Send out to Radio Do Loop Until Lof(#1)=1024 'Wait until Tx Buffer is clear DbMsg$ = "Radio output:" + Msg$+" #"+Str$(I) : DbPrnt StartTime=Timer Do Loop Until Timer > StartTime + TxTime OR Loc(#1) > 12 RCMsg$="" If Loc(#1) > 12 Then 'At least 12 characters in Rx Buffer Pause 100 'Allow time for the rest of the message RCMsg$=Input$(80,#1) 'Have reply ' Strip out the LINE FEED character from reply If Left$(RCMsg$,1)=Chr$(10) Then RCMsg$=Right$(RCMsg$,Len(RCMsg$)-1) If Right$(RCMsg$,Len(RCMsg$)-1) = Chr$(10) Then RCMsg$=Left$(RCMsg$,Len(RCMsg$)-1) EndIf If Left$(RCMsg$,3)="RTU" Then 'Check Reply is from targeted RTU 'Check for Pressure reply If Mid$(RCMsg$,4,2)= Mid$(Msg$,2,2) Then RCMsg$=Left$(RCMsg$,12) 'Check for probe reply If Mid$(RCMsg$,6,2)= Mid$(Msg$,2,2) Then RCMsg$=RCMsg$ Else RCMsg$="?"+ RCMsg$ EndIf DbMsg$= "Reply:" + RCMsg$ :DbPrnt Close #1 LkForMsg On Error Skip Open "COM1:9600" As #1 'Re-Open port to LoRa Radio Unit Exit For Else DbMsg$= Str$(TxTime/1000) + " Sec Timeout RTU" If Left$(RCMsg$,3)="RTU" Then DbMsg$ = DbMSG$ + Mid$(RCMsg$,4,2) Else DbMsg$ = DbMsg$ + Mid$(Msg$,2,2) EndIf DbMsg$ = DbMsg$ + " #"+Str$(I) DbPrnt EndIf 'Set alarm condition for remote If I = Retry Then DbMsg$= "Transmission Alarm RTU"+ Mid$(Msg$,2,2):DbPrnt AlarmOn EndIf Next I EndIf End Sub I am thinking that I will have to forensically examine the timing of the SendMsg sub. Regards Graeme (OA47) |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
The EndIf just before the End Sub looks odd. Unmatched? Misplaced? The logic about LF chars is ... unusual. John |
||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 926 |
John, I think you are right about that last end if. The logic for the removal of the LF char is to test for a missed one at the start of the message and the definite one at the end of the message. I had to do this to accommodate the Visual Basic software. Graeme (OA47) |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Well-spotted re ENDIF. More consistent formatting discipline might help to reveal such inconsistencies as the dangling ENDIF, i.e., indent after SUB, FOR, DO, IF until the closing command is reached (unless the entire command is on a single line). PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
I didn't count, just happened to see it - if it's dangling does the program work if it's fixed? John |
||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 926 |
I just checked the running software and that EndIf is not in the sub. I must have somehow added it when I cut and pasted into the post. I will synchronize the clocks and see if any other pattern occurs in the error codes. OA47 |
||||
Print this page |