How to solve System.Timeout.Exception on a PBX SMDR Capture app?

btw if you are going to create the port through code rather than dropping the object from the toolbox then you need to define it with events to get the events to work.

Code:

---

Dim WithEvents MyPort As New System.IO.Ports.SerialPort

---

In this case all code references would use MyPort
If you drag the one from the toolbox and do not change its name then all code references would be to SerialPort1

In no case should you do both and then add code MyPort=SerialPort1

Ok I get things settle down but still no result in the txtbox. I've made a breakpoint on DataReceived event to see if it enters. YES, it does but when I press F11 and search line by line results it shows me in the brackets correct ones but passes to the exception by telling me that Cross-Thread Exception on the txtReceived. Now am I supposed to use Delegate Subs and Threadings with InvokeRequired methods?

DataMiser I'm so grateful and thankful to your help regarding Serial Port in specific PBX connections. I now came to the conclusion my code works way better no exceptions. All I needed was another Invoke method in DataReceived event since the txtReceive textbox control was being created and handled in another thread. One last question is there any option to setup in the PBX to record and not to discard previous information, like lets stay to send me the last month call log? I have installed the Maintenance Console of the PBX machine in my workplace but hard to understand find if there is an option like that.

I thought you were working with a single threaded app now? Cross threading exceptions only occur in multi thread apps.

I have no idea about PBX, don't even know what it is. I have did a lot of serial port programming for other things though.

Hello back again. Thanks again for the help on how to. Now I'm having a result interface problem on textbox control. The message that is carried on the txtbox from the PBX (through RS232 port) somehow gets twisted instead of the regular one line format and it's like this "2/20/12 11:00AM 101 02 < DISA incoming >

00:00'31" .... 0". (with one enter, 3 spaces and an another enter addition than normal one line format). Is there something that I can fix this on the bytes received or the machine interprets it like that randomly?

This is the line code where it converts bytes and adds them as a string to text box:

Code:

---

txtReceive.Text = txtReceive.Text + x + vbNewLine

---

You are adding a newline after every read. Is there anythign in your incoming data that would indicate when one line is done and the next one begins? If so you can check for this and add the newline in the correct place. As is in any given read you could get part of a line and a newline character would be added to it via your code breaking the line apart. I do not know enough about your incoming data stream to tell you how would be best to handle it.

This is where I convert bytes to ASCII string

Code:

---

x = System.Text.Encoding.ASCII.GetString(comBuffer)

---

and this is in the DataReceived event where it joins that string to the existing textbox text

Code:

---

txtReceive.Text = txtReceive.Text + x + vbNewLine

---

In txtReceive_TextChanged event there is this code aswell which I think it might interrupt the format of text :

Code:

---

Private Sub txtReceive_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles txtReceive.TextChanged
        If Not txtReceive.Focused Then
            txtReceive.SelectionStart = txtReceive.Text.Length
            txtReceive.ScrollToCaret()
        End If
    End Sub

---

The thing is that your code will add a line feed after every read from the port. It is always possible that a read will be a portion of what is coming more likely with longer strings and slower baud rates. Increasing the baud rate on both sides may help if that is possible but ideally you need to know where one line ends and the next begins and insert your lnewline there rather than blindly appending it to everything that comes in.

I've written an application to log phone calls for a NEC NEAX 2000 PBX phone system. I believe your phone system works very similar to the NEAX 2000 (the format of smdr data might be different though). Basically, the phone systems continuously sends data down its RS232 port whenever a call is completed. And thus, in the application, you just need to set your serial port's data receive threshold to the number of bytes as your smdr record length, then handle the serial port data received event. In that event handler, you just read n bytes (where n is the smdr record length) from the port and then parse it into meaningful data.
The serial port data received event is raised on a separate thread, and thus if you want to display the data on your UI you need to code it as such (that is, you can't access controls on the UI thread directly from another thread as you're doing now in the current code)

Yeah Stanav, indeed. But here's the question where do I know how much should I set the datareceived threshold number to, by default it's -1...i mean that the length of the bytes received varies , it's dynamic every time a call is recorded in the PBX (panosonic). But skip this what I encounter as a logical problem is that the call duration of outgoing calls (the ones that you dial to make calls) is very unpredictable. E.g. if I start a call to 044111111 (not a valid number) and the beep tone rings for like 4-5 sec and then the person picks up the phone hangs the call and makes the conversation for an interval of let's say 20 sec. In the call duration it will show me total of 25 sec where as 4-5 first seconds where the beep tone ones. That's a very big problem if e.g. there is an international outgoing call e.g. from my country to Germany one and it rings for 1 min and makes a conversation for 2 min, total of 3 min call duration , it will charge the call for 3 min which is not an accurate result. Have any similar problems encountered or solutions for this one? I'd be grateful to hear anything from you.

One would think that there is a byte or signal that signals the end of a stream you may want to save the data driectly to a file then look at it with a hex editor.

You mean not to convert the bytes array into ASCII but normally insert them as they are and save into text file and search with hex editor?

Yes just as a test so you can view the output in the hex editor and see exactly what you are getting. It is possible that you are getting something in the stream that you do not see in your textbox and can be used to determine where to add a newline.

Gotta test on monday since now i'm set home and away from the PBX machine in my workplace. Ill inform you by the results. Stay tuned. I hope I'm not annoying with this topic. =)