Well done then I say!!
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.
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
Code: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 CCode: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
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
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
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...