LabVIEW inaccurate date computation

[drunkin_drum_er]

Hello,

For an existing test instrument rack under LabVIEW control the objective is to establish an automated capability that can validate measurement data based on equipment calibration status as follows. Add a VI that generates a text file with the test equipment ID list including calibration due dates in a 2D text array written to delimited spreadsheet file. A second VI reads that file, extracts due dates, determines status based on # of days to calibration relative to current year date such that if # of days > 30 item is tagged as 'OK', or, item is tagged with 'WARNING' if 0 >= number of days <= 30, or item is tagged with 'VIOLATION' when <0. The test system admin could extend the cal due dates by up to 30 days for equipment tagged with WARNING or VIOLATION status and this would update the cal due dates status in the 2D array and generate a new equipment list file with the updated cal due dates. Unfortunately, LV is not playing well in my litter box because for a 30 day extended cal due date the recomputed date should simply be the result of adding 30 days to the original due date. For example, adding 30 calendar days to a cal due date of 5/30/2020 should compute to 6/29/2020 but LV is doing it's own thing because it computes the 30 day addition with 7/3/2020 as the result. Help me LV-wan Kenobi, you're my only hope.

[mcduff]

It works for me.

mcduff

[altenbach]

---

@drunkin_drum_er wrote:

... LV is doing it's own thing ...

---

LabVIEW does whatever the program tells it to do. Writing a lengthy description without showing some simple demo code is insufficient to troubleshoot  the problem.

Sometimes problems are even due to poor programming, such as race conditions.

You already got some advice, but we should still get to the bottom of the reason you see what you see. So please show us some simplified code that demonstrates the problem.

[altenbach]

Another possibility:

[drunkin_drum_er]

Okay, I need to mention that I'm just a novice with regards to LV programming so please be kind as I'm very likely effing something up with my implementation. I have attached a description of the implementation with block diagrams that will hopefully help with this issue.

[drunkin_drum_er]

I do not accept what is presumed as the solution.

[altenbach]

It is unlikely that we can efficiently troubleshoot LabVIEW code from pictures. Can you attach a simplified VI instead?

Why are you carrying timestamp data as integer? What datatype is it before you convert it to I64?

[RavensFan]

I would take your red dashed ellipsed, make it larger, then throw out all the code it surrounds.

It seems like you are doing some awkward conversion from a data string, through integers, then feeding that integer into the Date Record function based on an integer which doesn't look right.  What is the significance of the constant 42369?

Here is what you do.

1.  Read your date string.

2.  Use Scan from String with the correct date/time format to convert it to a timestamp.

3.  Do one of the things Altenbach showed you earlier to add 30 days.

4.  Profits!

[DavidBoyd]

I'm adding a slightly simpler rendition of the timestamp offset example than Altenbach's.  This is (IMO) one of the places where LabVIEW's built-in units feature works for minimizing the number of nodes while being clean and self-documenting.  (Not often I don't take your word as the final say, Chris!)

Also, for the benefit of the OP, I added some BD notes about what you can, and can't do, with the timestamp datatype.

I looked through your Word doc, drunk_drum_r, and all I can say is, you're describing a LOT of unnecessary time arithmetic - LabVIEW's timestamp datatype is really the domain where you want to do this.  Since you seem to have a requirement for passing to and from text file format, I strongly suggest you learn about the Format Into String and Scan From String nodes, especially the %<>t format specifiers, to save yourself a lot of extra pain.

Best regards,

Dave

 

[altenbach]

---

@DavidBoyd wrote:

I'm adding a slightly simpler rendition of the timestamp offset example than Altenbach's.

---

Yes, my code was just a curious alternative to mcduff's earlier code. Personally, I would stay away from units, but that's just me. 😉