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

[btcomp]

I have SUCCESS! I was able to see the error of my ways, and I was able to get the protocol to properly start the upload to the CNC 88 and also to end. The start is TA,1 followed by line feed, carriage return then a %. The ending is a % followed by a line feed, carriage return. I also add BYE. I decided that the port must close between running the programs, and then using the OpenComPort method I can generate a unique file name to store probing data for each program. Pretty slick and thanks Jan.

Now I do have a problem in the ending. It seems that as long as the file uploaded is 3k or so, I get the whole program uploaded to the CNC and I get a proper termination message. But when the file is 7k, the formText variable is not sending the latter part of the file to the CNC 88 and then I don't get the proper termination, though the file will usually register as being loaded. Not sure I under formText as it seems to grab the datareceived data in chunks. I probably need to know more about RS-232 ports. I do have Jan's book so I will be studying it.

But just a happy success, because I did save three under 3k program files and I had success with the upload and with the datareceived from the probing part in the CNC. 

[btcomp]

I have been playing around with the program this morning, and wonder about the lines in ComPorts module. When I changed these values I was able to get more data read. I am going to try different values when at work, but I really need to understand what is going on here? This is in the OpenComPort method.

                       

Code: [Select]

SelectedPort.ReadTimeout = 5000
                        SelectedPort.WriteTimeout = 5000

[Jan Axelson]

Start with Microsoft's documentation:

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

Jan

[btcomp]

Thanks Jan,

I'm in the shop and I was successful changing the WriteTimeout to 12000. I will read the documentation. The below is good for the demo I am going to do. It was driving me nuts yesterday until I realized that timing and real-world stuff has to be considered when working with computers!

Code: [Select]

SelectedPort.ReadTimeout = 5000
SelectedPort.WriteTimeout = 12000

[btcomp]

After having success with the timeouts, I am now have another problem. You see the object of the program I'm using is to allow the VB.Net software to enable the old (yes old about 1985) CNC 88 to work with the PC, and currently it's connected to COM 1 of the XP Professional computer. For the most part this is fine, and the communications is at 9600 baud. Now CNC use what is called G-code, not an expert myself with this code. But what was possible in 1985 was the ability to send a new file, to the memory limited CNC 88. This is done directly by the path, (eg. C:\DATA\PROG1) which is easy. But I have been unsuccessful, getting errors and then also RS-232 errors. This led me to believe that for the path command to work, assumes the communication is at the command line of DOS.

So I am thinking that my program, (actually most is Jan's Serial Port Communication program, but which I have added and modified for this project. I have four forms now, having added a program listing form, though I don't think it's needed.

I have programmed at the command line in VB and C#, though it's not my favorite mode. Is it fairly easy to make a new VB.Net project and copy and paste most of the code. This has a good chance of working, though the CNC 88 manual does say that some Windows DOS may not work, in their 1999 legacy manual update.

I think with that I'm going to go home and think on this a bit and start writing a couple of small Console Applications to get used to using this type.

[btcomp]

I am now connecting to the CNC 88 controller (one of the company's oldest controllers) and able to send text data one line at a time, called 'drip-feed' which is probably the best way to work with the machine, and to be able to keep the machine running for hours.

Drip-feeding is as it sounds, think of an IV in someone to keep them alive, just continually adding fluid to a person. Now I am trying to turn on or off handshaking, as was suggested to me by a programmer of CNC controls. I was told to set handshaking to None when I got the Xoff signal

So I try something like this:

       

Code: [Select]

'Set a delay first and adjust the amt time needed. BT-14Jul2012
        Threading.Thread.Sleep(125)
        UserPort1.SelectedPort.Handshake = Handshake.XOnXOff

Below is what I found out on doing this, but this guy in Ohio, doesn't use .Net which my company wants to use. I don't know if this all makes sense. I wasn't really sure why you turn the handshake to None and then to Xon/Xoff?

Open your COM port and set the handshake property to "None".   This will let any Xon or Xoff characters pass through the serial port device driver, so you will be able to "see" the operator press the READ button.  Get your file ready to send, then wait for an Xon character to come in from the CNC.    As soon as you see an Xon, set the handshake property to "Xon/Xoff", then begin sending data.  Your software will send characters until your COM port control's output buffer is full, then it will stop until the buffer is near empty.  Your software will be perhaps several K-bytes ahead of where your CNC is during the transmission process.   Your software will finish sending the entire file well before the CNC gets the last of it, so DON'T CLOSE THE PORT when you're done sending until you're sure that the CNC has actually received the end of the program.  I usually watch the output buffer on the COM control and wait until there are zero characters left.   Closing the port before that time may interfere with the port's ability to handshake with the CNC.

[HDowns]

If you'll set software flow control to XOn/XOff then a serial port driver will intercept Xon and Xoff characters and you'll not get in your code.

Software flow control is None - you can detect a time when an operator press the READ button

Software flow control is Enabled - the file will be sent to the machine in the drip-feed mode automatically and you will not need to control data flow manually by analyzing incoming data.

[btcomp]

HDowns, I believe I went and just turned on XOn/XOff completely. Now I can try that again, where I start with NONE and then change to XOn/XOff just before I start drip-feeding. By the way, I found a solution to the program stopping after one line. SPRINT sent drip-feed on CNC 88, mayber other machines too I don't know as of yet, causes program execution to go to the end on the CNC control, something I don't believe I want. SO I took out all SPRINT commands, and the machine danced perfectly, it did all the simulated probes. BUT no data to record. So, I believe Macros will help, not a perfect solution, but not a perfect world. I am going to try subprograms and I think this will work. But I will want to study the handshaking. I also may need to find a better insertion point for starting and stopping my data files. Presently when I want a new data file, I first close the port and then open it again. I do this though when no data is being sent. This may not be the best way of doing it, but at the time, I wasn't sure where else to do this. If I find a spot to do this that doesn't require the port to be closed I will move my routine there, I think that makes sense and I understand the ComPorts program a bit better than I did a month ago when I set that routine up.

[ydsjhb]

If you just want to be able to read serial data from the machine, you could start with my COM port terminal application:

Lvr.com/serport.htm#my_example_code

Look at the DataReceived routine.

__________________

Sonnenbrille Ray Ban Damen

[btcomp]

That's what I have done. And I succeeded. Now what I am not able to do in CNC Land, the land of computers in a real world of machines, is to read the SPRINT lines in DNC mode, or Direct Numerical Control, I believe. I am doing this using drip-feed method. You feed the cnc control with enough program code, to keep at least two lines of code visible on the monitor, analogy is the hospital patient on an IV.

What I discovered though is what is code G code, the data of CNC. The G31 command is a probing command. And you can use P1 P2 and P3 and you get back X Y Z data in these points. That works! Now I don't know if I can get the same measurements, but if I can then I can write the labels to match the P data.

If you are confused by this, so am I. But I intend to figure a way, because I can see data coming back in drip-feed and if so then it should be doable to both send instructions to the CNC as well as receive data back.

[btcomp]

Okay on the drip-feed method of DNC, I am able to get my data. The X, Y and Z coordinates of the location of a probe gives three dimensional information. The DataReceived method is working, (i.e. X1.45Y-2.5Z1.555T). The info is there, I just have to format it, no big deal. HOWEVER, in drip-feed as the name implies I am adding to the data going in. Now I want to either create a new file to store DataReceived when a new file is loaded and sent to the CNC controller or at least put in a statement separately the data.

Below is my code:

Code: [Select]

Friend Sub DataReceived(ByVal sender As Object, ByVal e As SerialDataReceivedEventArgs)
        Dim newReceivedData As String
        '*********************************************************BT-25Apr2012
        ' Dim FILE_NAME As String = "C:\RCMTools2012\rs232" & TimeOfDay.Ticks.ToString & ".txt"
        Dim objWriter As New System.IO.StreamWriter(FileName, True)
        '*********************************************************BT-25Apr2012
        Try
            ' Get data from the COM port.s

            newReceivedData = SelectedPort.ReadExisting

            ' Save the number of characters received.

            ReceivedDataLength += newReceivedData.Length

            RaiseEvent UserInterfaceData("AppendToMonitorTextBox", newReceivedData, Color.Black)
       
            '*********************************************************BT-25Apr2012
            objWriter.Write(newReceivedData)

            objWriter.Close()
            '*********************************************************BT-25Apr2012
 
        Catch ex As Exception
            DisplayException(ModuleName, ex)
        End Try

    End Sub

I can't seem to figure how to add data to the open text file that is being written with data on the RS-232 port. I should also add that I create a new text file when I open the RS-232 port, COM 1. I had intended to close and open the port to create a new file. That isn't going to work here, as I will need to keep the port open during drip-feed.

The procedure is to Start the CNC controller by physically pressing the 'Green' start button. That is the only manual process. Once this happens, the process should continue, drip-feeding. When the 'Green' start button is pressed the port will be closed and opened and stay opened until the drip-feed is done, which may last just a few minutes, but more than likely will continue several hours.

[btcomp]

Wow, a lot of progress since I wrote just a few days ago. I have my data from the computer sending to an array the data sent to the CNC controller. Now the received data is coming and I also send it to an array in the ComPorts module. I access the ComPorts array and send the X, Y and Z coordinates values into a string variable from the array CNCX(200), CNCY(200) & CNCZ(200) as strX, strY and strZ. But the values are blank in my textfile. I am thinking that, actually know that the file is being written before I can get to the data, but tried to put a pause in the file I am writing to text and appending as the the data coming from DataReceived takes longer, by using  a While-End While loop. I tried checking for 'empty string', 'null' or 'nothing' but that isn't working. I get errors telling me

I may have to just write the file separately in the ComPorts module and then combine the two files later in time, when the cnc milling machine has caught up to the processed code! They let me stay here at the shop by myself, but going to go and get dinner and work on tomorrow. I think I am almost there, if I could just get my main program to slow down and smell the roses so to speak and wait for the DataReceived to catch up.

I put in some code belowl

Code: [Select]

'TESTING- SEND Array Data to a file.
        Dim strX As String  'Testing this. BT-1Aug2012
        Dim strY As String
        Dim strZ As String = ""

        Dim objArrayFile As New System.IO.StreamWriter("C:\DripFeed\files\array_trial1.txt", True)
        Dim Count As Integer
        For Count = 1 To no
            'This may have to be modified. I am going to try it tonight & if successful go home and research. BT-1Aug2012 in Romeo, MI
            '  While UserPort1.CNCZ(Count) = Nothing

            '  End While

            strX = UserPort1.CNCX(Count)
            strY = UserPort1.CNCY(Count)
            strZ = UserPort1.CNCZ(Count)

            While strY.Length <= 0
                strY = UserPort1.CNCY(Count)
            End While


            objArrayFile.Write("Probe No. = " & Count.ToString & " " & Prgm(Count) & vbCrLf & SprintTxt(Count) & vbCrLf & SprintD1(Count) & " " & strX _
                               & vbCrLf & SprintD2(Count) & strY & SprintD3(Count) & " " & strZ & vbCrLf & vbCrLf)





        Next

        objArrayFile.Close()

[btcomp]

Okay, Progress! today! I finally got it. The CNC data is being sent to the CNC control and I'm getting back data from the DataReceived procedure and two things worked. One, my arrays though I could access the variables weren't loading with data. And I not only had to make them Public but also Shared. I will have to study the terminology more, but I tried this and it worked. Code below:

Code: [Select]

Dim PrgmNam As String = "M"
    Dim SubNo As Integer = 0
    Dim no As Integer = 0
    ' Dim RevCam(200, 200, 200, 200, 200, 200, 200) As String
    Public Shared Prgm(200) As String
    Public Shared SprintTxt(200) As String
    Public Shared SprintD1(200) As String
    Public Shared SprintD2(200) As String
    Public Shared SprintD3(200) As String
Now the other thing that was causing problem was the way I was trying to read the array! Think and the . I was trying to read both the data I sent, and receive when the computer was done, but the machine was way behind. So I reversed this, and created both sets of arrays but read them as the DataReceived came in. This of course had to be done in the raw form as the CNC 88 is not capable of sending any data back in what's called DNC or a direct line by line drip-feeding. Fortunately programmers design the software and hardware that runs these machines, who else! So I was able to do this. Now the work begins. I don't know if the firm knows how much, but I'm sure there is lots. And I still have to fine tune what I have already.

Thanks Jan for your serial port program, as it has been the workhorse making this work.

[Jan Axelson]

Glad to hear of your success! Thank you for sharing what you learned.

Jan

[btcomp]

Well I have been making progress with this program, and was able to actually change data sent to the RS-232 port after data has been flowing. But I believe this was done after I finished sending all the data I had to the CNC controller. The trick now is to be able to jump around in the program based on the data coming back from the CNC controller. I have been able to monitor the slow tortoise, milling machine as the fast hare PC sends it's data. So now I just take away the data after a analysis point is needed, and I'm trying to wait for the data to come back after reading all the data I send to the CNC controller.

The problem is the milling machine slows way down for me as I stop the data flow and compare the data number from the CNC controller, which is 15 for testing. The data sent to the CNC is stopped after data number 15 also is sent. I have been putting in message boxes to see what is happening, and I am getting numbers in the millions for the number of times the data is being compared to see if the CNC controller has sent back 15 data points.

One thing I am going to do, and have done, is try to slow the computer way down in sending just a few instructions more than the CNC needs. There needs to be at least a couple of data lines for the CNC controller to be happy theoretically. It's buffer of course can handle much more than that.

I am also finding that if I have message boxes in the program, when I click ok on them, the milling machine responds quicker and goes through it's motions faster. So I do believe I need to throttle the speed the data is going to the CNC.

But if there is anything that I might help in improving the communication to the serial port that would be helpful. That is the part of the program that is giving me some grief. And though I am trying to get the other people in the project to actually do some milling so I can get some real data, for the present time I have to be happy with just simulating the milling without actually cutting any steel.