What is happening is info from one child form is being received or listen to by the wrong child form.
-
What is happening is info from one child form is being received or listen to by the wrong child form. The situ is one parent form and any number of child forms. Specifically this is a truck control system, all the the truck/child forms are the same. But the monitoring and controls for each are to be independent of the other's actions. Example one truck could be in neutral with a rpm speed of 800, while another truck is in 3rd gear with rpm of 1000. So the situation has to be contained within the logical confines of the individual childform/truck. I've tried using access modifiers to there extent. Making things 'private' as much as possible, getting rid of as much 'static' as possible. What is first sent is the info packet. Defined as: !!!780;125;1400;0;5000&&& The truck sends back a string of data for processing, and as confirmation of what's wanted by the operator. The string looks like this: I5000R0780G02O099C060V23.3W2440F099L4S01400P00000X126Y057B27.08H65253E01T01D0000_99! Within the program I'm using a ID_Parser to strip/read out the identifier at the beginning of the string to make sure it gets sent to the right form. Actually creating a instance of the truck/chilform that the info belongs to. I had to do this because sometimes the sending form would receive info string from another truck. This routine does put the port_in into the proper truck and its accompanying array: public static string[] Trux_Info = new string[20]; The letters designate different pieces of information 'I ' designates id of the truck in this case truck5000, the 'R' is rpm, 780, followed by gear and so on. The transmission is by RS-232, on the parent form, constantly open. Each truck sends/ reads through this, and the buffers, in and output, is flushed after each use. I've tried individual comports per childform, but had unaccessible issues. As I have ran out of ideas and test methods I asking if anyone sees what I'm missing. Further definitions, test methods, and results are provided as an attachment. Is there way to attach attachments, I have them already zipped.? Thanks
-
What is happening is info from one child form is being received or listen to by the wrong child form. The situ is one parent form and any number of child forms. Specifically this is a truck control system, all the the truck/child forms are the same. But the monitoring and controls for each are to be independent of the other's actions. Example one truck could be in neutral with a rpm speed of 800, while another truck is in 3rd gear with rpm of 1000. So the situation has to be contained within the logical confines of the individual childform/truck. I've tried using access modifiers to there extent. Making things 'private' as much as possible, getting rid of as much 'static' as possible. What is first sent is the info packet. Defined as: !!!780;125;1400;0;5000&&& The truck sends back a string of data for processing, and as confirmation of what's wanted by the operator. The string looks like this: I5000R0780G02O099C060V23.3W2440F099L4S01400P00000X126Y057B27.08H65253E01T01D0000_99! Within the program I'm using a ID_Parser to strip/read out the identifier at the beginning of the string to make sure it gets sent to the right form. Actually creating a instance of the truck/chilform that the info belongs to. I had to do this because sometimes the sending form would receive info string from another truck. This routine does put the port_in into the proper truck and its accompanying array: public static string[] Trux_Info = new string[20]; The letters designate different pieces of information 'I ' designates id of the truck in this case truck5000, the 'R' is rpm, 780, followed by gear and so on. The transmission is by RS-232, on the parent form, constantly open. Each truck sends/ reads through this, and the buffers, in and output, is flushed after each use. I've tried individual comports per childform, but had unaccessible issues. As I have ran out of ideas and test methods I asking if anyone sees what I'm missing. Further definitions, test methods, and results are provided as an attachment. Is there way to attach attachments, I have them already zipped.? Thanks
None of this makes much sense. I can't work out how your long info string has anything to do with the title.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
What is happening is info from one child form is being received or listen to by the wrong child form. The situ is one parent form and any number of child forms. Specifically this is a truck control system, all the the truck/child forms are the same. But the monitoring and controls for each are to be independent of the other's actions. Example one truck could be in neutral with a rpm speed of 800, while another truck is in 3rd gear with rpm of 1000. So the situation has to be contained within the logical confines of the individual childform/truck. I've tried using access modifiers to there extent. Making things 'private' as much as possible, getting rid of as much 'static' as possible. What is first sent is the info packet. Defined as: !!!780;125;1400;0;5000&&& The truck sends back a string of data for processing, and as confirmation of what's wanted by the operator. The string looks like this: I5000R0780G02O099C060V23.3W2440F099L4S01400P00000X126Y057B27.08H65253E01T01D0000_99! Within the program I'm using a ID_Parser to strip/read out the identifier at the beginning of the string to make sure it gets sent to the right form. Actually creating a instance of the truck/chilform that the info belongs to. I had to do this because sometimes the sending form would receive info string from another truck. This routine does put the port_in into the proper truck and its accompanying array: public static string[] Trux_Info = new string[20]; The letters designate different pieces of information 'I ' designates id of the truck in this case truck5000, the 'R' is rpm, 780, followed by gear and so on. The transmission is by RS-232, on the parent form, constantly open. Each truck sends/ reads through this, and the buffers, in and output, is flushed after each use. I've tried individual comports per childform, but had unaccessible issues. As I have ran out of ideas and test methods I asking if anyone sees what I'm missing. Further definitions, test methods, and results are provided as an attachment. Is there way to attach attachments, I have them already zipped.? Thanks
I've read that about 5 times and I'm still not sure! So you have several external devices connected to the same comport (?) represented in your software as 'child forms', and all the control is done through one 'parent form' that holds the comport connection?
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus) -
What is happening is info from one child form is being received or listen to by the wrong child form. The situ is one parent form and any number of child forms. Specifically this is a truck control system, all the the truck/child forms are the same. But the monitoring and controls for each are to be independent of the other's actions. Example one truck could be in neutral with a rpm speed of 800, while another truck is in 3rd gear with rpm of 1000. So the situation has to be contained within the logical confines of the individual childform/truck. I've tried using access modifiers to there extent. Making things 'private' as much as possible, getting rid of as much 'static' as possible. What is first sent is the info packet. Defined as: !!!780;125;1400;0;5000&&& The truck sends back a string of data for processing, and as confirmation of what's wanted by the operator. The string looks like this: I5000R0780G02O099C060V23.3W2440F099L4S01400P00000X126Y057B27.08H65253E01T01D0000_99! Within the program I'm using a ID_Parser to strip/read out the identifier at the beginning of the string to make sure it gets sent to the right form. Actually creating a instance of the truck/chilform that the info belongs to. I had to do this because sometimes the sending form would receive info string from another truck. This routine does put the port_in into the proper truck and its accompanying array: public static string[] Trux_Info = new string[20]; The letters designate different pieces of information 'I ' designates id of the truck in this case truck5000, the 'R' is rpm, 780, followed by gear and so on. The transmission is by RS-232, on the parent form, constantly open. Each truck sends/ reads through this, and the buffers, in and output, is flushed after each use. I've tried individual comports per childform, but had unaccessible issues. As I have ran out of ideas and test methods I asking if anyone sees what I'm missing. Further definitions, test methods, and results are provided as an attachment. Is there way to attach attachments, I have them already zipped.? Thanks
Hi,
Lecutus1 wrote:
I had to do this because sometimes the sending form would receive info string from another truck.
That is the sentence I noticed in your post because unexpected data read from the serial port is indicative of a fault. The question is why is bad data being received? Where to route the response is relevant only when the data is good. From your description each request that is sent is tagged with a truck ID. I assume that all trucks attached to the serial port will receive the request but only one will recognise the ID and respond using that same ID. Is that correct and can you verify that all the trucks operate correctly? Clearly only one truck should be allowed to respond at a time as overlapping responses at the serial port would cause all sorts of trouble. Problems of this nature can be avoided by ensuring that a response is received for each request before a further request is issued. If this send-receive protocol is strictly obeyed then routing the response to the correct form is straightforward as the expected response ID is always known. If a situation ever arises where response ID != request ID then something has gone very wrong and the status of the truck is unknown. Do you wait for the response to each request and check that a full response has been read before parsing it? That is just a few things for you to think about. Let us know how you get on. Alan.
-
Hi,
Lecutus1 wrote:
I had to do this because sometimes the sending form would receive info string from another truck.
That is the sentence I noticed in your post because unexpected data read from the serial port is indicative of a fault. The question is why is bad data being received? Where to route the response is relevant only when the data is good. From your description each request that is sent is tagged with a truck ID. I assume that all trucks attached to the serial port will receive the request but only one will recognise the ID and respond using that same ID. Is that correct and can you verify that all the trucks operate correctly? Clearly only one truck should be allowed to respond at a time as overlapping responses at the serial port would cause all sorts of trouble. Problems of this nature can be avoided by ensuring that a response is received for each request before a further request is issued. If this send-receive protocol is strictly obeyed then routing the response to the correct form is straightforward as the expected response ID is always known. If a situation ever arises where response ID != request ID then something has gone very wrong and the status of the truck is unknown. Do you wait for the response to each request and check that a full response has been read before parsing it? That is just a few things for you to think about. Let us know how you get on. Alan.
Thanks Alan As to the first question, I'm not recieving bad data, I've got a filter for that, I'm recieving data from another truck. Your absolutely right as far as write and wait for a response before moving to the next truck. I'm still trying to get used to the timing of this RS232 and its behaviour. Once again this was a case of overcooking the goose, in other words I did too much, too quickly when a a little less could have been used. Thanks once again
-
I've read that about 5 times and I'm still not sure! So you have several external devices connected to the same comport (?) represented in your software as 'child forms', and all the control is done through one 'parent form' that holds the comport connection?
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus)In effect yes, each truck is to be timesliced, a chance to send and recieve data by itself. The maincontroller, parent form, contains the comport feature. The parent form also creates an instance of each truck when its time for that particular truck. I hope that clarifies. I have a zip file of a more defined situ. Unfortunatley I haven't found a place to apply an attachment. Thanks for reply L.