LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

date/time to seconds bug when passed to subVI?

Hi, I've converted the time data for my x-axis using the date/time to seconds function and it works just fine as standalone vi. However, I want to do these operations in a subvi then pass the data to another vi which does the graphing. For some strange reason, the seconds data is being converted to negative seconds in the order of around -1349000000. I can't understand how this is happening. The data for y-axis remains unchanged and the graph looks perfect except for the fact that the x-axis has these big negative numbers and of course just say 'Neg' if I format the axis to time and date. Can anyone tell me if I've missed something obvious? I have a main VI set up as a state machine and in this state have the data subVI
wired straight to the graph subVI

Regards, Paul.S
0 Kudos
Message 1 of 12
(3,367 Views)
Check the data representation for date/time connector of the subvi and the other vi to make sure they are both sufficient to hold the values.
Message 2 of 12
(3,367 Views)
thanks Aderogba - you're quick off the mark! Actually the data was somehow changing its representation somehow... I don't really understand exactly what was wrong, but by passing out the arrays separately (instead of wiring the graph to the terminal), I just stored them as unsigned longs in the graphing VI and passed them to the graph from there - problem solved. Can anyone explain why my data was mysteriously 'converted' from unsigned long to int when it was passed out of the subVI?

Regards, Paul.S
0 Kudos
Message 3 of 12
(3,367 Views)
> the graph from there - problem solved. Can anyone explain why my data
> was mysteriously 'converted' from unsigned long to int when it was
> passed out of the subVI?
>

There shouldn't be a mystery, the rules of how LV chooses types are
hard and fast, but without seeing the VI I will be left with listing
off a few guesses.

Data doesn't go to the subVI connecor directly from the diagram. You
always make an indicator on the panel as well. That indicator
determines the type leaving the VI, not the wires on the diagram.

A useful tip when getting specific about type is to open the help window
and switch to the wiring tool. As you hover over a particular wire, the
help window will give you detailed info about its type. You can then
com
pare that to the terminal symbols and figure out what is causing
what. Another tip that some use is to open Tools Options and set the
diagram's coercion dot color to something brighter. Once you know where
to look, the gray dots are easy to spot, but some prefer to make the red
or magenta. These dots appear everywhere LV automatically changes type
to avoid breaking a wire.

Greg McKaskle
0 Kudos
Message 4 of 12
(3,367 Views)
thanks Greg, I am definitely going to be more careful about the way I do things in future. Since the moment I encountered it I have considered LabVIEW to be absolutely amazing in it's power and ease of use - I guess the downside of this is that it makes it so much easier for dimwits like myself to 'hack' together code and then wonder why it isn't doing what it's 'supposed' to...

Cheers, Paul.S
0 Kudos
Message 5 of 12
(3,367 Views)
maybe while I'm at it I should ask you what 'image depth' is in regards to the get image property and jpeg vi's, as I can't seem to find any documentation and experimentation seems to indicate valid values are 2, 4 or 8..., but I don't really understand what the parameter is defining. Are there valid values above '8' which will give me a 'better' picture?
0 Kudos
Message 6 of 12
(3,367 Views)
> values are 2, 4 or 8..., but I don't really understand what the
> parameter is defining. Are there valid values above '8' which will
> give me a 'better' picture?

That really should be better documented. The depth number refers to the
number of bits per pixel. Other valid values should be 16 and 24, with
24 being True Color or Millions of Colors, or whatever else the OS calls it.

Greg McKaskle
0 Kudos
Message 7 of 12
(3,367 Views)
thanks Greg, in that case, something strange is happening, where if I change to above 8 I don't get an image. Do you think you can take a look? Also, you will notice I have the control reference wired to the invoke node - do i need to 'close' this reference or pass anything 'out the other side' in order to avoid problems? If so how?

Regards, Paul.S
0 Kudos
Message 8 of 12
(3,367 Views)
?
0 Kudos
Message 9 of 12
(3,367 Views)
Paul,

I was curious about your vi to write a chart as a jpeg. Thanks - now I know how to when I find a need for it. I've looked at some of these vi's before but the documentation is pretty slim so I haven't tried them too much.

I tried your vi and looked into the the subvi's of Write Jpeg File.vi.

First thing I did was to look at the error output of the Write Jpeg File.vi. I could not write a file with a depth value of 2. Only 1, 4, and 8. Did you get it to work with a value of 2?

Check out the subvi's of Write Jpeg File. The subvi Check Data Size.vi allows only values of 1, 4, 8, and 24. All other values will produce an error. I would think that 1 = B&W, 2 = greyscale, 4 = 256 col
ors, 8 = 16 bit color, 24 = 32 bit color.

The next subvi, Check Color Table, oddly also allows a value of 2 in addition to 1, 4, 8, and 24. Depth = 24 case is handled differently than the rest. It requires that the color depth be an array of zero length.

See the attached modification, which should let you write with a depth of 24.

Sorry I can't lend any insights as to WHY depth = 24 is handled differently. Don't know enough about it.

Good luck,
Tim Shanahan
0 Kudos
Message 10 of 12
(3,367 Views)