Serial bus-- bytes at Port returns 0 with termination character disabled

[Bhalt]

Hi Lynn and crossrulz,

Thanks for the suggestions. I am now splitting up the false case to check for 1 character at a time. It will also reduce the wait time for the VISA read. I assume the bytes remain in the buffer until they are read...

I will post the final vi once it is full y tested, for anyone to see and use (?).

Thanks a lot.

Bhal

[Bhalt]

Folks,

I have completly tested the attached vi and it does what i want it to do. So I am posting it as FYI for anyone to use, modify or whatever. I have some other problems relating to this project which will post seperately so that this post it terminated.
Thanks.

Bhal

[johnsold]

Thank you for letting us know about your progress.

Here are a few suggestions:

1. Local variables are not the same in LV as in text-based languages.  A local is primarily a means of gaining access to the data in a control or indicator.  The "real" variable is the wire.  The use of local variables is prone to race conditions, requires a copy of the data, and is slow to execute.  While this may not be a problem in this VI, you should get out of the habit of using locals.  Just wire directly to the control/indicator terminals.

2. Avoid running wires behind other objects.  It makes you code hard to read and surprisingly often hides errors.

3. The selector and the 1 and 0 constants can be replaced by Boolean to (0,1) for a simpler and cleaner diagram.

4. If the Pkt To Be Sent values ever need to change while the VI is running, the terminal need to be inside the loop.

5. (True case) It takes about 1 ms to send or receive a byte at 9600 baud. If Bytes at Port executes less than 1 ms after the VISA Write, or the remote device has a slight delay in sending the reply, you could miss the reply.  If you really want to read one byte at a time, eliminate the Bytes at Port.  The VISA Read will wait (up to timeout) for the byte and then return as so as it gets it. If more than one byte is sent in response, you  will get a mismatch at the =? test.

Lynn

[Bhalt]

Hi Lynn,

Thanks for your several suggestions. While the vi runs ok for now, I have much to fix it seems. Your comment on the local variable was news to me as I was using them liberally to "get rid of wires" everywhere as I read in one of the posts. In fact it may be the source of one of my other major problem with the overall project which results in the PC blue screen of death, indicating I was bloaing up memory..

I will try to incorporate your suggestions and post the results, after testing..

Help much appreciated.

Bhal

[Bhalt]

Hi Lynn,

I fixed up several, if not all of the errors as per your suggestions. In particular your comment that the wire is the real data and I should avoid creating and using local variables is an important one. THe user manuals don't seem to emphasize that, at least in my reading. But the problem of "Windows blue screen of death" does not seem to go away. It is random and I know it is (most likely) due to my vi not releasing the allocated memory. However, having looked at the 3-4 vi's involved, I am at a loss as to where the memory creep is and more important how to solve it. Appreciate if you or anyone can address this in a generic way as it might be illuminating to all future readers.

So I am attaching all the files in the project. The main vi is BL_State_Machine_New_Test.... 

Here is a short description of this Boot Loader project. I have a .hex (object) file which I want to download to a (custom) device. I have constructed a state machine which transitions as follows.

>Init

> GetBlkCount (finds how many blocks of 64 bytes are there and creates a BIN FILE)

> Connect (connects to device) {vi not attached}

> Send Pkts (Synchronizes with the HW)  > Creates a pkt from BIN FILE > downloads the pkt and loops around till all packets are loaded

> Stop (Closes VISA Port).{vi not attached}

I could not attach all vi's but I think the problem may be detectable using these 3..

I suspect that the BIN FILE is the source of the problem (it is about 30K bytes of binary). However I don't know how to purge it or why the whole things runs sometimes and blows up sometimes quickly but always blows up after 3-4 runs.

Any help in identifying the source of the problem and fixing the problem would be appreciated...

Bhal Tulpule 

[johnsold]

Bhal Tupule,

It is not obvious as to what is crashing your computer.

You definitely should close the file after you read it. I do not use Windows, so I am uncertain what the call to the System Exec.vi is doing.  Are you doing something with the same file (temp.hex) in two places? I could see that causing conflict, depending on how the OS responds to multiple calls to perform actions on the same file.

Use of multiple event structures in one program can cause problems. Also putting event structures inside a case structure can cause problems. Neither should crash the OS but both may lock up the front panel.  Read the caveats about use of the event structure in the detailed help files.

The use of the Wait for Front Panel Activity two places seems inappropriate.  Consider a Producer/Consumer (Events) Design Pattern. I think that was available in LV 8.6.  Put the event structure in a parallel loop. It can have multiple cases rather than the multiple structures you now have and there will be no need for the Wait for Front Panel Activity.

You might try initializing the Bin file string shift register with an empty string.  Since you only write to the shift register one time, this is likely not the problem.

Try to avoid having wires and other objects hidden behind the case structure or other objects.  For example I could not tell where the while loop termination terminal (the stop sign) was or what was wired to it.

If you want to attach more than three items, compress them into a zip file and attach that.

Lynn

[Bhalt]

Hi Lynn,

I am attaching a zip file which has all the vi's and a .hex file (object file) that want to download. I understand and know that there are many errors and I need to fix them. however, none of them seem to be capable of crashing the windows PC. I even increased the disk space, just in case. I know it is not possible to test this as you or anyone else do not have the hardware device to which this Boot Loader downloads. However I think that's irrelevant to why it crashes IMHO. One could eliminate that part (SEND_A_PKT vi) and I think it would still crash.. So I am doing something structurally that windows/LV do not get along on...

Any help/ insight would be appreciated.

Thanks.

Bhal Tulpule

[johnsold]

I noticed one thing: You open the serial port in Connect. You open the serial port in SYNC.vi (in the Basic Serial Write and Read.vi) and then close it. Very soon after that you open it again in Send_A_Pkt_Rev5.vi and do NOT close it.  Since opening and closing the serial port are tasks performed by the OS (at the request of LV, but not performed by LV), it is possible that the OS could have a problem with this.

Open the serial port one time, in the Connect state and pass the VISA Resource Name Out to other states via a shift register, then write and read as needed in the Send Pkts state (without any open/configure/close), and close the port in the Stop state.

Lynn

[Bhalt]

Hi Lynn,

Thanks for your suggestions.

I looked at my vi’s and you are right there were too many port opens and file open/close etc. I can’t believe it ran even this far with that many errors. I think what happened was that they were stand alone vi’s and to test them I had all these things added. I should have taken them out.. I am new at this…

Anyways I think I cleaned up all that and guess what  !! It ran all the way from beginning to end. (I had added a STOP button in the stop state.) !!!

However, on subsequent runs, w/o any further changes I got the blue screen… So it can’t be a fluke that it ran all the way to the end…

So I think this has something to do with the WIN OS interaction with LV. Otherwise it should not have run even once, IMHO.. Can you take a look ?

I have attached the revised vi’s in a zip file. Appreciate if you can look at it and provide some insight...

Anyways, I am going to try do some more testing/ changes to see if it will run. One change I am considering is instead of opening the file and changing the pointer during each iteration to get a new packet, I want to copy the .BIN file to an array and then index the array. It think it used to run that way before all these changes. Do you think that is the problem it is blowing up ?

Another technical  question is the use of local variables. I use a local variable NO_OF_PKTS, just to avoid passing all those wires. THat variable is inside the case. What is the impact of that ? Does LabVIew create a copy each time the loop in entered ? It in only 1 Byte so I can't imagine it would be crashing memory. But anyways, I would like to better understand what is the impact of creating local variables and whether they should avoided.

Thanks.

Bhal Tulpule

[johnsold]

I do not know what is crashing your computer.   I see several things which may cause problems with your VI, but most of them should just make it work wrong.

1. The Menu will always read an old, stale value when the event structure in the Idle state fires. You do not need the conversion to boolean array and Search array. Just wire the New Value Event Data Node in the Event structure to the state enum selector.

2. You do not need both an Event structure and Wait for Front Panel Activity.  The Event Structure waits.

3. File Size input to Get_Next_Pkt.vi in SendPkts state will aways be zero. The Use Default if Unwired tunnel on the case structure is the problem. Wire straight through any case where the data is not used.

4. Why do you suppress the error dialog and then clear errors in Get_Next_Pkt.vi? If any file errors occur, you will never know.  This is one place where your blue screen problem might exist. If you set the file position to some disallowed value and then try to read from that position, who knows what the OS might do?  I would monitor those errors closely rather than clearing them.

5. Make_Next_Pkt_Rev1.vi is full of race conditions. You have no way to know whether the Value property nodes will execute before or after the terminals are read or even whether they will always execute in the same order. Use dataflow to make them do what you want. IF you need to set the values of controls programmatically, it is usually better to use local variables.  In this case it is not at all clear why you would want to set them within the subVI.

6. Why are you using Bytes at Port in Send_A_Pkt.Rev6.vi? You always read only one byte.  Due to the time required to send a byte at 9600 baud (~1 ms) the value will likely be 0 or 1.

7. Put No_of_Pkts on a shift register. Move the indicator outside the case structure. Eliminate the local variable.

8. In the Stop state it would be better to wire a Not A Refnum constant to the output tunnel.  After the file is closed, the refnum which was on the shift register is no longer valid.

9. Remove the STOP function.  Wiring True to the loop termination terminal is enough. This STOP could also be part of your crash problem. Using STOP is the same as pressing the Abort button on the toolbar. It stops th eprogram immediately without allowing things to close normally.  As long time Forum participant Ed Pickens once said: "Using the Abort button to stop a VI is like using a tree to stop a car. It works but there may be undesirable consequences!"

10.  Your stop button does not do anything because it is not wired to anything.

Lynn