Huh? I've never seen it do that.

[thisisnotadream]

Please check out this code that I'm working on.  I am taking some J1708 data and splitting it up amongst multiple messages if the data is greater than 20 bytes.  The first split should be 14 bytes of data, subsequent splits occur in 15 byte or less chunks.  The VI just does not work...that's not the weird thing.  The weird thing is that the Build Array VI is behaving weird in the for loop.  I am constructing a byte array of size 2, the first time the data is bad (unexpected outputs when probing the inputs), the second time through the loop, the data is still bad but this time the array is like 20-something bytes long.  After running the VI more than two or three times, LabVIEW crashes...

I have tried copying the block diagram elements to a new VI of a different name.  I have even tried rewriting the VI from a printed copy to eliminate corruption issues...

Does this VI behave the same for anyone else..It is written in LV 7.1?

[johnsold]

Please provide some data and the expected results for that data. When I run the VI with a string of printable characters it does not crash, but the results may not be what you expect either. I used the Profiler to check for memory leaks or changes in timing and saw neither after >1000 runs.

Lynn

[thisisnotadream]

I have attached a screenshot of what my results look like with the input:

(hex) 0102 0304 0506 0708 090A 0B0C 0D0E 0F10 1112 1314 1516 1718 191A 1B1C 1D1E 1F20

Expected values:

Array[0] (hex) 01C0 1202 201E 0304 0506 0708 090A 0B0C 0D0E 0F10 [don't care byte, checksum]

Array[1] (hex) 01C0 1202 2111 1213 1415 1617 1819 1A1B 1C1D 1E1F [don't care byte, checksum]

Array[2] (hex) 01C0 0402 2220 [don't care byte, checksum]

[johnsold]

Just a quick note to tell you what I have found so far.

1. I get Insane object messages when saving or compiling. That usually indicates that something has gotten corrupted.
2. The build array node inside the for loop generates arrays with 3, 17, and 32 elements on successive iterations should be 2, 2, 2 ?!?!?! I replaced it with a new one and get more nearly correct results. If I wire the array to an indicator outside the loop, then the array size indicator is correct?!?!?!

I suggest that you build a new VI which has the same structure as this one. DO NOT copy or drag any parts of this one to the new one. Just look at it and make the new one look like it. Something is seriously corrupted with this VI. I think it would be faster (and safer) to make a new one than to try to fix this one.

Lynn

[thisisnotadream]

OK.  That's kind of the scary thing. 

What you are looking at now is exactly that.  My first step in troubleshooting was to print out the bad VI.  Then close it and open a new blank VI.  Then I proceeded to recreate the original VI using the pallettes, not cutting and pasting.  The VI that I posted was the result of this effort. 

I guess the next step is to delete both VIs, close LabVIEW, restart the computer, start LabVIEW, open a blank VI, and reattempt to recreate the VI.

PS--The behavior you noted above was exactly the problem that I was noting, causing me to write in.

Message Edited by thisisnotadream on 11-21-2005 08:26 AM

[thisisnotadream]

No change!  God must really hate me.

And the insane object is back...how crazy is that?!!

[thisisnotadream]

OK.  I have a work-around.  I still can't figure out why writing it in 7.0 is an issue, but when I write it in 7.0 and open it in 7.1, it works...Anyone who wants to investigate this bug is welcome to it.

Here is a screenshot of the expected results:

[johnsold]

It is scary. You may have corrupted one of the elements in LV's palettes.

Here is a copy I made which has no insane objects and executes. Bytes 2-5 differ from what you expected, so there may be an algorithmic error.

Lynn

[thisisnotadream]

Scary isn't the half of it.  I just don't want to have to go through the hassle of having our computer folks reinstall.

I looked at your implementation, I am pretty sure the differences are related to your flipped logic on when to add that extra original size byte to the header.  It only is to be sent on the first message.  You have it being sent on every message after the first.

Thanks for your help and a second opinion to make sure that I wasn't going crazy.

Dan