Problems in syncronyzing two threads into Test Stand using a Global Variable (TestStand 4.1.1)

[RayFarmer]

one additional thing, your TCP_Receiver_Handler picture is showing error 66 which is

'The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools»Options»VI Server:Machine Access on the server side'

Make your you have setup the correct premission.

Regards

Ray Farmer

[teodor_blaga]

OK... Let me Explain you the LV Code and sequence. I try it to adapted for a short example and I didn't think that is too hard to be understand.

Receive_HDL_Block picture:

1. Ther is a while loop that is reading all TCPIP communication.

2. If there is new data which meands some new commands in my protocol transsmission I will process them with 'number 3' to add a time stamp in front of each received command.

3. The output of number 3 is previous buffer plus the new added commands

4. If I receive something I'll process the string with number 3, otherwise I'll pass the previous one.

5. The 'FileGlobal.TCP_Receive_Buffer' string variable is written always with the actual value of the shift register.

6. The 'FileGlobal.TCP_Receive_Stop' is a boolean that will stop the loop which I intended to run it as a new thread.

7. 'Size in bytes' it is a length of a command from my protocol which can be represented in word or doubleword. So nothing important for the TestStand problem.

Receive_HDL_Front picture:

1. Data out is an hex representation of the output string. And by convention with previos step 'number 5' this should be written into test stand as it is. But because of the first 0x00 character reched by TestStand this will truncate the output string. (THIS IS MY REAL PROBLEM)

2. That error 66 is comming because the ethernet connection is closed because of a side effect of not triggering an watchdog. So it is OK to be like that. It will stop my TCPIP aquisition

Receive_Read_Bufeer pictures:

1. I create this application just to read continously the output of previous one application via the teststand variable 'FileGlobal.TCP_Receive_Buffer'

Sequence picture:

1. Execute previous described labVIEW applications with an 'Action procedure' from TestStand.

2. This is done in the sequences 'Check the receive buffer' and 'Receive Handler' defined as new threads that are running in background.

3. These sequences will use 'FileGlobal.TCP_Receive_Buffer'and 'FileGlobal.TCP_Receive_Stop'to exchange data and also to be stoped at the end of the execution

4. The rest is skipped, except the TCP Open and Close connection sequences  and the stopping of loops using the last statement which will setup the 'FileGlobal.TCP_Receive_Stop' variable to True.

5. There is also a Wait for Receive_Handler to Stop. This is happend when the communication is lost right now (Explanation to error 66 from LV code).

6. The sequence is not perfect made and is used for my own timming measurements.

I hope I didn't miss anything important to my problem which is the received 0x00 character which will truncate the read string. And this is because of the TestStand string variable type, because LV code is able to read it.

So my question is: How can I specify to a TestStand global string Variable to read all characters from it and to do not stop it to the first 0x00 one.

[RayFarmer]

Convert your string as an array of U8's and pass the array to TestStand. You would need to change your FileGlobals to an array of numbers.

Regards

Ray Farmer

[teodor_blaga]

Yes this is one of the workaround (that you proposed), but I hoped in the end that Test Stand will be able to act like LabVIEW in case of the Strings Variables defined in it.

I added here also a better package with my problem.

I'll try a few workarounds but I would prefer to keep my string in the end instead of arrays.

If you have some specific Testand Setup idea the case will remain open.

Thank you

P.S. I used TestStand 4.1.1 and LabVIEW 8.6 for the files. I hope to do not have problems with it during its openning and running.

[dowNow]

Hi,  Regarding: hoping that TestStand will act like LabVIEW, I have often hoped this, but they are two different products and you can not count on this. imho definitely lose the Global Variable and redesign around a que of strings.

cc

[RayFarmer]

can you save out your sequence file as version 3.5?

Regards

Ray Farmer

[Teds]

See attached.  Convert your "HEX" data you are transmitting to a NORMAL String Display before sending it to the FileGlobal. I have seen other engineers where I work having problems with how TestStand handles HEX data.

For example, Transmit.vi contains a string in HEX Display: 3030. Convert this to Normal display string of 3030.  See the new VI called 'Convert to Displayable Comamnds'.  Send this value to the FileGlobals.Buffer.

Change your Receive.vi 'Received Bytes' string to be in Normal Display and not HEX Display.

Thanks,

Paul Holzrichter

[teodor_blaga]

Hi,

Thank you all for supporting me in solving this problem. All ideas were good from implementation point of view. But as I said the workaround will be a LabVIEW one. I will add also this one (which was also discussed in principal) which involves a few casts to byte arrays and the other way arround into strings in the LabVIEW files.

Anyway it is amayzing that I didn't touch the keyboard to do all the modifications. Less then 20 mouse clicks...

Thank you

P.S. I saved also a 3.0 version for Test Stand Sequence.