Simple VB.Net RS-232 program to capture serial port data to a text file

[Jan Axelson]

Here is a tutorial that covers marshaling data to a form:

http://www.codeguru.com/csharp/csharp/cs_syntax/threading/article.php/c10755/Safe-Multithreading-with-the-BackgroundWorker-Component.htm

And again, in my ComPortTerminal example, take a look at the AccessFormMarshal routine and associated code, which passes data to a form for display.

http://www.lvr.com/serport.htm#my_example_code

[btcomp]

Thanks Jan, I have printed the article and will look at your example again. I had trouble understanding the MyBase but I think with the extra resource you posted I should be able to make this work. The data is there, I see it in my messagebox, but in DripFeed mode, many of the machines are restricted to just the data, so my dripfeed method filters it.

[btcomp]

I am going to put some breakpoints in your AccessFormMarshal method. I am still having a hard time understanding this. But I guess I need to know how to do this, so that I can call my 'filtering dripfeed routine that is the MainForm, because I am sending additional data on the RS232 port directly from the ComPorts module.

[btcomp]

I still must be doing things wrong. However, I haven't seen that I have an error showing. I just am not going to the DripFeedCNCDataParts routine or perhaps I am not getting out of the loop. I can't debug on the machine, and I haven't been able to get an old Windows 98 computer to communicate with my Laptop through an RS232 cable that connects the two, if I could do that I could probably test this part of the program at home, which would be ideal for me.

Below is the code that is supposed to trigger the RaiseEvent. I don't know if it does, but the line underneath, that shows a MessageBox, and lists the contents of the string does not show when the RaiseEvent line is added. Without the line it does.

Code: [Select]

ElseIf BoolMustBePerfect = False And x = UBound(file2Data) - 1 Then
                '  MessageBox.Show("Why did this happen?")
                WriteToComPort("#PRINT" & Chr(34) & "THE DATA WAS NOT WITHIN TOLERANCES!" & Chr(34) & vbCrLf)

                WriteToComPort("#PRINT" & Chr(34) & "RUN THE NEXT INCREMENT" & Chr(34) & vbCrLf)

                '  WriteToComPort("G0 H99 Z0.100" & vbCrLf)
                ' WriteToComPort("G0 X1.8333 Y-1.5975" & vbCrLf)
               
               
                strProbeAgain = MainForm.strProbe(1, 1)

                RaiseEvent FilterNCCode(strProbeAgain) 'BT-25Oct2012

               
                ' WriteToComPort(strProbeAgain)


                ' WriteToComPort(MainForm.DripFeedCNCDataParts(strProbeAgain))
                MessageBox.Show(strProbeAgain) 'Comment out again, so as not to be a

I posted four snapshots of where I added code so that I could run: RaiseEvent FilterNCCode(strProbeAgain) 'strProbeAgain should have the filtered data to send to the RS232 port. This routine also sends the data to the port, so I have commented the 'WriteToComPort here.

[attachment deleted by admin]

[btcomp]

Okay it really is working. I had a mistake in my third image in my last post, as I had left out one line, so I have the fix below. ALSO, I changed my DripFeedCNCDataParts from a function to a sub, and the other parts also were of course changed to a sub, didn't really need this as a function. The data was processed and sent, though I do get an error on the CNC machine, but it really is sending and I assume doing some multithreading.

 

Code: [Select]

Private Sub AccessFormMarshal(ByVal action As String, ByVal formText As String, ByVal textColor As Color)

        AccessFormMarshalDelegate1 = New AccessFormMarshalDelegate(AddressOf AccessForm)
        Dim args() As Object = {action, formText, textColor}

        ' Call AccessForm, passing the parameters in args.

        MyBase.Invoke(AccessFormMarshalDelegate1, args)

    End Sub


    Private Sub DripFeedCNCDataPartsMarshal(ByVal strFile As String)
        DripFeedCNCDataPartsMarshalDelegate1 = New DripFeedCNCDataPartsMarshalDelegate(AddressOf DripFeedCNCDataParts) 'Added this BT-26Oct2012

        Dim args() As Object = {strFile}
        ' Call DripFeedCNCDataParts, passing it the one parameter
        MyBase.Invoke(DripFeedCNCDataPartsMarshalDelegate1, args)
    End Sub

[btcomp]

At the shop this Saturday and I have fixed the error that occurs, on the CNC controller side. The multithreading is working great. The command I have setup is telling the controller to rerun the Probe data strProbe(1,1) and it is hard coded here for now. The first filtered data that goes into the RS232 port is supposed to be T2M6 followed by a VBCrLf. But the port sniffer showed the first character lopped off so that 2M6 only was sent. (For those that familiar with CNC Milling T1M6, T2M6, T3M6 ... tells the mill to get the tool in location 1, 2, 3 ...

The solution to this for now is to insert a blank line in front of the data being sent so that I am sending WriteToComPort("   " & VBCrLf)  or in my case, I may need to just put this line in whenever the program first sends data in my DripFeedCNCDataParts routine. I am going to add that.

Now I will have to see if my strRef(50,5) array data will parse correctly. I have been using a text file as my test, but this will not be hard, it's not rocket science.

Finally, I am thinking that I should put in an Xmodem method for this. The reason being is that I am thinking the older CNC machines will work better for extremely long runs, 10 or more hours or even days. So that is going to be a bit of a challenge. I know that 132 bytes are sent, with 128 used for data and the last four to work with the checksum. I have found an XModem module to look at, and I have sample port-sniffing data for this. The CNC controller sends back an 06Hex as my port-sniffing program has shown.

[btcomp]

The owner of the tool shop is concerned with the time taken on this project, and though I believe I have made lots of progress, you know time is money to people. Sometimes I think we programmers are not understood and I know the owner doesn't and I don't believe anyone in the shop knows, though Dakota working on the wireless probe for this project does. The owner seems to believe that the Xon/Xoff is not working and wants to know how long it will take to do this in XModem. And I am not going to try to explain to him the difference because he doesn't really understand all this. I am just a geeky guy and that is all he knows. The whole shop guys and a couple gals are a great bunch of people so I am not complaining, and times are tough I was happy to be employed on this project and I hope he doesn't think I am just wasting his money.

SO I am thinking that XModem with 128 bytes of data with 4 bytes for using for Checksum, though I am not sure how I am going to do this, but will research this. I think the program can easily be modified to add a routine to send the data piecemeal in 128 byte chunks, and this is after the initial coding DNCX 0,0,0 is sent. The parameters are optional. There is a mandatory 2 second delay, I have been adding about 2.5 seconds minimum myself. But since I have the program already setup to send line by line and now character by character I don't see any problem with 128 byte chunks, filling empty bytes with either zeros or spaces.

I am posting a sample that I captured off a newer CNC controller.

Port opened by process "NCFadal.exe" (PID: 57728)


Request: 10/16/2012 3:42:21 PM.39364


 41                                                A               


Answer: 10/16/2012 3:42:21 PM.39364 (+0.0000 seconds)


 41                                                A              


Request: 10/16/2012 3:42:21 PM.39364 (+0.0000 seconds)


 40 0D 44 4E 43 58 2C 30 2C 30 2C 30 0D 0A         @.DNCX,0,0,0..


Answer: 10/16/2012 3:42:23 PM.01864 (+2.0000 seconds)


 44 4E C3 D8 AC 30 AC 30 AC 30 8D 0A 15            DNÃج0¬0¬0.. 


Request: 10/16/2012 3:42:23 PM.01864 (+0.0000 seconds)


 01 01 FE 25 0D 0A 0D 0A 0D 0A 47 31 37 47 38 30   ..þ%......G17G80
 47 39 30 47 38 45 31 0D 0A 4F 32 28 44 45 54 5F   G90G8E1..O2(DET_
 30 36 30 32 29 0D 0A 28 54 4F 4F 4C 30 2E 31 38   0602)..(TOOL0.18
 37 35 44 49 41 30 2E 30 39 33 37 52 41 44 29 0D   75DIA0.0937RAD).
 0A 47 31 54 32 4D 36 46 31 30 30 2E 0D 0A 53 34   .G1T2M6F100...S4
 32 30 30 4D 33 0D 0A 47 34 33 48 32 5A 33 2E 37   200M3..G43H2Z3.7
 30 38 31 4D 38 0D 0A 47 31 58 2D 30 2E 33 37 35   081M8..G1X-0.375
 59 31 2E 38 37 35 46 31 30 30 2E 0D 0A 5A 33 2E   Y1.875F100...Z3.
 37 30 38 88                                       708ˆ           


Answer: 10/16/2012 3:42:23 PM.04964 (+0.0000 seconds)


 06                                                .              


Request: 10/16/2012 3:42:23 PM.04964 (+0.0000 seconds)


 01 02 FD 31 0D 0A 5A 33 2E 32 39 0D 0A 47 31 5A   ..ý1..Z3.29..G1Z
 33 2E 30 39 46 32 30 2E 0D 0A 47 31 58 2D 30 2E   3.09F20...G1X-0.
 33 35 34 33 46 33 30 2E 0D 0A 58 2D 30 2E 32 33   3543F30...X-0.23
 36 32 0D 0A 58 32 2E 38 37 35 0D 0A 47 31 59 31   62..X2.875..G1Y1
 2E 38 37 31 34 5A 33 2E 30 39 30 36 46 32 30 2E   .8714Z3.0906F20.
 0D 0A 58 32 2E 38 37 34 38 59 31 2E 38 36 37 38   ..X2.8748Y1.8678
 5A 33 2E 30 39 0D 0A 47 31 58 2D 30 2E 33 37 35   Z3.09..G1X-0.375
 46 33 30 2E 0D 0A 47 31 59 31 2E 38 36 34 32 5A   F30...G1Y1.8642Z
 33 2E 30 15                                       3.0.           


Answer: 10/16/2012 3:42:23 PM.08064 (+0.0000 seconds)


 06                                                .               

Then this is the last block that was sent after several dozens of code sent for this 15 minute project.

Request: 10/16/2012 4:08:07 PM.38664 (+0.0000 seconds)


 01 95 6A 33 30 2E 0D 0A 47 31 59 2D 31 2E 33 36   .•j30...G1Y-1.36
 37 35 5A 33 2E 30 39 30 37 46 32 30 2E 0D 0A 59   75Z3.0907F20...Y
 2D 31 2E 33 37 31 31 5A 33 2E 30 39 0D 0A 47 31   -1.3711Z3.09..G1
 58 2D 30 2E 33 37 35 46 33 30 2E 0D 0A 47 31 5A   X-0.375F30...G1Z
 33 2E 37 30 38 31 46 31 30 30 2E 0D 0A 47 39 47   3.7081F100...G9G
 32 38 0D 0A 4D 32 0D 0A 0D 0A 0D 0A 25 0D 0A 00   28..M2......%...
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 8D                                       ...           


Answer: 10/16/2012 4:08:09 PM.77764 (+1.3594 seconds)


 06                                                .               


Port closed

[btcomp]

Now I have been told to try and add XModem routine to the project. I have a class that has a couple of routines I can use, but in using XMODEM an ACK  06 is sent back, or NAK, etc.  This may work out better. But I have to turn of Xon/Xoff for this I believe.I am capturing data (see image). The DNC stands for Xon/Xoff Dripfeed, sending DNCX would cause the CNC controller to work in XMODEM. Will I be able to capture both the text XYZ data and the ACK, NAK ... control characters with no flow control?

The image shows the data which is received after the initial DNC handshake. Sometimes the probe data comes one probe point at a time, but often as many as 50 points at one time. With Xon/Xoff I don't see any other characters. The probe data starts with an X (or Y or Z if used),or an N or T occasionally. There is always one control character after each probe data point. (0Dhex)

[attachment deleted by admin]

[btcomp]

An  update on XMODEM, I have it working, though you have to use NO flow control, that is keep Xon/Xoff to none. You depend on the receiver sending 06hex ACK and 15hex NAK. Now the routines I have work, but I'm thinking I have some communications problem I am going to have to single-step through in SendPacket and SendFiles routines of the modules I imported into Jan's program. These routines are in the MainForm in a routine I call DripFeedCNCDataParts which is the 'meat' of my program. I send all data through this routine and I use it with the Xon/Xoff method of data transfer and works okay. Now I needed to add XMODEM so I wanted to use the same DripFeedCNCDataParts routine. But it needs to be called from ComPorts module and I successfully setup this with RaiseEvent following Jan's method with the AccessFormMarshal routine. So in XMODEM with CRC checking I send 128 bytes of data, which is actually 132 bytes, the first three bytes are the numbering of bytes with 01 01 FE and then 01 02 FD ... and the last byte is the Checksum byte which is calculated and thanks to Dick G. for the modules I imported.

What happens is kind of strange. What I think Fadal with it's CNC controller is doing in XMODEM is sending ACK (06hex) is that it also will send a NAK (15hex) and keep doing this at short intervals, such as 1/2 second or so. This is followed by 11hex (DC1) and then again 15hexs. This repeats until the next XMODEM 132 byte packet is sent.

Well I may not have the communication perfect and/or timing. And putting in appropriate delays is important, but you don't too much delay. Ideally you want to have 06hex followed by a new packet or if you don't get a 06hex then you would get just the 15hex (NAK). Then you would resend the same packet.

Okay, I am getting some success, as the packets are going through and the machine is working, going through the motions of milling, probing, etc. BUT, I make a program change based on the probing data. This program change is not known until the probing is done. This is where the RaiseEvent works and I can send one of two data files depending on the probing data. This happens immediately and is sent. BUT, when I do this, the packets all get sent at one time, and then followed are the responses (all of them) at once!

I will attach a file of this, so it makes sense. I am wondering if  the fact that the SendPacket and SendFiles routines are in MainForm that I having this problem. Or maybe I have some delay in between running the different files that is causing this. I am going to keep working on this and report back what I find, I probably won't be back to the shop until Tuesday but I am going to single-step the SendPacket routine, because I still don't understand how it all works.

I have indicated in the image where the response is before I send the data with the RaiseEvent call. But using the RaiseEvent method does not give me a quick response but rather all the data is sent at the end. For a large amount of probing, I'm sure this would err.

I noticed that the SendPacket routine is Private, I am thinking that maybe it needs to be Public and or  Shared? I won't be back to the shop until Tuesday. but

[attachment deleted by admin]

[Jan Axelson]

The documentation for DataReceived says:

The DataReceived event is not guaranteed to be raised for every byte received.

http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx

This discussion might be helpful:

http://stackoverflow.com/questions/7808226/datareceived-event-sometimes-doesnt-fire

[btcomp]

Thanks Jan. Just saw your  response and I will be looking at the  (ReadBufferSize and ReceivedBytesThreshold) and experimenting with this tomorrow. I am psyched up from this. I am also posting another image, as I want to show the data received in orange being delayed at the end, I see that my drawing clipped this. So the new image will show. NOTE, too that my data returned is mixed in with the control bytes of 06hex, 15hex ... This does not pose a problem since I know that all data for the CNC machines either will start with the first coordinate that is requested, in my case a Y but it could be X or Z and if nil or not data it will be either an N or a T . Kind of weird the T as I am thinking it means terminal or something where N means either nil or no data. I hope I haven't been confusing? But the data does come back consistently all data comes back with a 0Dhex which is my 'guiding light' to parse.

In the image notice the Y coordinates, my data, and the N for no data which just means I didn't generate a probe value so it is NIL, as well as 06hex 0Dhex which follows all data, and possibly 1 15hex or even a 11hex, though it may not be visible in this snapshot.

[attachment deleted by admin]

[btcomp]

I am getting the (attached image) System.NullReferenceException error in immediate window and InternalSubstringWithChecks with exception Length cannot be less than zero in my Xmodem run. This causes the CNC controller to send a 93Hex, which I believe is what they have programmed the controller to send when it cannot continue. These show up as symbols in the textbox.

[attachment deleted by admin]

[btcomp]

Disclaimer, I am not Brad Pitt, but rather his better looking alter-ego! 

[Jan Axelson]

Track down the source of the exception! This might help:

http://www.dotnetperls.com/nullreferenceexception

[btcomp]

Thanks Jan, I have bookmarked the link. It will come in handy for me. I am not sure I will be working more on this project. I believe this is the last day. I have an issue with a module in XModem from Dick G. program. I feel drained, as I have worked hard on this, the only programmer on the project, actually at the plant. But they can't seem to understand the need, or have the money for a full-time person and actually could benefit from two people. Anyway I am going to be busy with the PacketTimeout Method of Dick's. That is where I have some problems. It may not be solved today, but will be in my notes of what needs doing if the owner decides he wants me (or someone else) to coninue, and if I'm available, which is looking like I might not be. Unfortunate because the guys all love me here, and ditto from me. 

Will keep informed and I'm here for the next four hours at least!