System variables

[YoDoug]

Holy Crap Batman!
How the heck did you come up with that set of formula?
Brain hurts just reading it.
Cheers
Brian.

The VQDAT variable is a day counter from the starting point of 12/31/1979. If you look at the value of VQDAT today (8/20/2013) it will be 12286. What we are after is the Julian Day Number for today. This is accomplished by adding the Julian day number for 12/31/1979 (2444238) +VQDAT. The Julian day number for today can be converted using the formula below to get the date in Gregorian calendar. I did not come up with the formula, it was developed by some guy name E.G. Richards. I just converted it to run in OSP.

[broby]

Well done then I say!!

[iMillJoe]

The VQDAT variable is a day counter from the starting point of 12/31/1979. If you look at the value of VQDAT today (8/20/2013) it will be 12286. What we are after is the Julian Day Number for today. This is accomplished by adding the Julian day number for 12/31/1979 (2444238) +VQDAT. The Julian day number for today can be converted using the formula below to get the date in Gregorian calendar. I did not come up with the formula, it was developed by some guy name E.G. Richards. I just converted it to run in OSP.

Oh wow, the Okuma epoch, handy info!

Bravo!

I solved a Euler Problem similar once, but in a more advance language. Really, that was pretty good.

[deadlykitten]

hello i know that this thread was started some time ago, but maybe i am not late, since such stuff is still actual

a few years ago, i was looking for a method to use timestamps inside my programs, and google returned this thread

thank you YoDoug for sharing those code samples; it helped me a lot, and this thread convinced me to join the cnc-zone

now, i would like to share coding tricks, that speed up the execution time

thus next infos are not about customizing the output of the code, but the way it works ( compiled )

below are 2 programs that generate identical outputs : 2nd program executes 2x-3x faster

- 1st program : code from #7 with a few modifications :
... ' close c ' before ' fwritec ' is removed, because it closes a sessions that does not exist
... ' MD1: ' is removed, since writing to a local folder <> main system device is not possible, and MD1 is default
... removed the repetition of the PUT' ' & WRITE C from the begining
... TIME-DATE >> time-date : i discovered that i like lower case
... PUT' ' >> PUT ' '
... execution time : 162 - 192ms

- 2nd program :
... $noex , $0D0A
... indentation
... ' WRITE C ' is used only once
... execution time : 67 - 80ms

i shared this, because a timestamp ( or whatever log ) code may create additional machine downtime, thus it may interrupt the machining flow, and there are persons that can see when a machine is stoping, even if it 'waits' only 0.1 seconds; about this, i have some 'work in progress', trying to minimize the downtime / kindly

FWRITC time-date-v1.txt;A


(TIME DATE)
PUT ' '
WRITE C
PUT 'YEAR/MM/DD'
PUT VTIME[1]
PUT '/'
PUT VTIME[2]
PUT '/'
PUT VTIME[3]
WRITE C
PUT 'TIME'
PUT VTIME[4]
PUT':'
PUT VTIME[5]
WRITE C
CLOSE C

    FWRITC time-date-v2.txt;A
    NOEX PUT ' '                                                                          PUT $0D0A
$        PUT 'YEAR/MM/DD' PUT VTIME [ 1 ] PUT '/' PUT VTIME [ 2 ] PUT '/' PUT VTIME [ 3 ] PUT $0D0A
$        PUT 'TIME'       PUT VTIME [ 4 ] PUT ':' PUT VTIME [ 5 ]
    WRITE C
    CLOSE C

[deadlykitten]

hello citizens, previous post shows how to tune a classical code, so to reduce it's execution time from 160-190ms, to 67-80ms

now, i wish to share you another trick, to reduce the execution time even more, so to achieve an average <15ms : remove close-c

the trick behind this, is that "fwritc" is assigning a file to the buffer, and close-c is removing the assignment, so to allow you to assign, later, a different file; if you are writing data to a single file, then you may avoid close-c; simple, isn't it ?

purpose is to minimize downtime created by logs; the way to implement it, is to achieve a real execution time, for the logging process, that is much smaller then the deviation of the cycle time; for example, if cycle time is 30±0.35 seconds, and data logging requires:
... >1 seconds/cycle, then there is too much downtime caused by gathering data
... < 0.1 seconds/cycle, then the data can be gathered without adding downtime to the cycle

so far, i have had the oportunity to prepare setups that would last for months, delivering more than 10k parts; achieving a stable line, without downtime, requires perseverence

whatever, i am not saying that what i do is the best; no ... i only try to do my best so far, the only thread that i have found about this issue, is this one : https://www.cnczone.com/forums/okuma...ing-times.html, and in there, at post 5, it is said that, because of the downtime created, logging is used only for diagnostics; it is possible to keep it on, all the time, but this is another story / kindly