[broby]

Does anyone know how to read the system date and time on a Okuma OSP-E100M?
So far all I can seem to find is a system variable that tells me how much elasped time since power on in either Days, Hours, Minutes or Seconds using the VDIN[1000] (Free running counter, 0.001 Seconds)
VDIN[1001] (Free running counter, 1 Second)
VDIN[1002] (Free running counter, 1 Minute)
VDIN[1003] (Free running counter, 1 Hour)
VDIN[1004] (Free running counter, 1 Day)

Using the internal Clock variables VPMNT,VRMNT,VPHUR,VRHUR and VQDAT gives me strange results.

I know the system has a Day and Time stored somewhere as Macman uses it to write information to the Macman reports. Also, it does not reset when the machine is restarted.

Any help would be welcome.

Regards
Brian.

[slavetothemetal]

Broby:
Are you simply trying to monitor cycle time?

[broby]

There are quite a few reasons that I would like to be able to "Read" this information, not just for cycle time monitoring, but yes, basically the reason is monitoring.
The reason I do not just use the macman reports is that I can only identify that a certain program has run at a certain time and date, but I can not then identify what Job number the program run is associated with!
Currently, I set job number and job step numbers into common variables and then read and store the value of the free running counter (seconds) in a common variable at the start of the program, then re-read the same counter at the end of the program. The only problem I have come across with doing this is when the machine is restarted between the reading of the start time and the reading of the end time, the total cycle time ends up being a negative number! Subtracting one from the other gives me the cycle time and along with the information stored about the job number, I can write this to a file for report writing.
The other Major reason for not using the Macman reports is that Macman only tells me the cycle time when the cycle is running... using the counters I get a better idea of how long a job has taken, including time stopped with checking sizes, threads etc...
Cheers
Brian.

[slavetothemetal]

broby,
I just went to the "Partners in THINC" in SC a little while ago, and I asked similar questions. The short answer is, you will not be able to access the system clock. Okuma did not allow anything even through the API on the P200 controls. The reason, they sell a much more in-depth MacMan suite of products. I looked at these, and they are VERY nice, but pricey. I can't recall on the E100, but can't you check the OSP system variable for the Sequence Restart flag? Also, along this same line, possibly switch your M00 and M01 codes to use macro programs called by M-code. Then you could start and stop the counter inside the macro without anyone seeing it? I will look into this more today, as far as the details of how to make it work. It's an Okuma, I am 99% sure there IS a way to get it done, just a matter of making my Fanuc-driven head look at it right.

[broby]

Hi Slave...
It certainly does seem to be that access to the system clock is blocked, a real bummer that!
When you are referring to changing the M codes to start and stop the timer, sight unseen, well this is not what I am after!
I do not want to have the program "timer" started and stopped through out the program!
I have set up custom codes to "start" and "stop" the timer, or should I say more accurately, record the start and end time of the program run time.
It is just that I would like to be able to record the Date and Time also, not just the total run time of the program run.
Cheers
Brian.

[slavetothemetal]

Hey Brian,
I was only referring to a possible solution for the operator intervention issue. I have worked with operators that would do all kinds of silly things to keep the machine from running at 100%, and I thought that was possibly similar. I do have a call in this morning with a really sharp applications engineer, I will be sure to let you know what comes of it.

[Bala]

hi broby
could you please give me some samples to use time and date variables such as VPMNT,VRMNT,VPHUR,VRHUR and VQDAT.

[broby]

Hi Bala,
What is it that you are trying to acheive with your request?
I am trying to only figure out how to write the time and date that a job was run to a csv file that I am currently writing to anyway.
Macman provides me with the time and date when a program ran, but I can not also get from macman details such as job number, operation number etc... hence the use of a custom written program that records this information along with the time the job has taken to run.
The time to run is reliant on the user running a "Timestart" program and then when the job is leaving the machine, a "Timestop" program.
I get the total time by reading the free running counter for seconds at the start and end of the job.

for example Macman produces a file...
DAILY MACHINING REPORT[2007/11/24]
MACH NAME:MA600HB
DATE/TIME:2007/11/25 6:41:29

#MS-100-DW
START DAY TIME NO. WORK OPER % RUN OPERATE CUT CYCLE MACHINE
BLOWDOWN.MIN
07/11/25 06:15:18 1 100 125 125 53 125 125
TIMESTOP.MIN
07/11/25 06:15:15 1 50 2 1 0 2 1
MA6OP2-11529654.MIN
07/11/25 03:46:57 1 89 8897 7948 7702 8897 7948
TIMESTART.MIN
07/11/25 03:46:50 1 50 2 1 0 2 1
TIMESTOP.MIN
07/11/25 03:46:48 1 100 1 1 0 1 1
MA6OP1-11529654.MIN
07/11/25 01:57:28 1 97 6559 6410 6140 6559 6410
TIMESTART.MIN
07/11/25 01:57:24 1 100 1 1 0 1 1
PALLET-CHANGE.MIN
07/11/25 01:57:06 1 100 17 17 0 17 17
etc...

As you can see in this file, I have the time and date of when the program has run, but I need to know how long a "job" has been in the machine, not just the cycle time of the program, after all, if the operator has to inspect something "in process" and the program is not running during this inspection, or tip change... then I need to know, as this affects the costing of the job.
After all if a program runs for 30minutes, but the "job" is in the machine for 60 minutes, I want the customer to pay for 60 minutes, not just 30 minutes!

As a result of this problem, I made up a "Timestart" program that outputs the following information to a CSV file:

Job Number,Confirm No.,OP. Number,MATERIAL No.,Time secs,Day,Month,Year

The program also writes the current value of the free running seconds counter to a common variable.

At the end of the job, the operator runs the "Timestop" program (or at least the schedule program does...) and the line of information out put to the same CSV file looks like this:
40029151, 834048, 2, 11529654, 8904, 24, 11, 2007

Combined together in the file the output looks like the following...(for the above run of programs)

Job Number,Confirm No.,OP. Number,MATERIAL No.,Time secs,Day,Month,Year
40029381, 838346, 1, 11529654, 6563, 24, 11, 2007
Job Number,Confirm No.,OP. Number,MATERIAL No.,Time secs,Day,Month,Year
40029151, 834048, 2, 11529654, 8904, 24, 11, 2007

Some times the operators forget to run time stop, which causes a few problems trying to sort out the file for costing purposes, but that is where I use the Macman file to compare against. Bit of a pain in the butt process sorting the files out sometimes, but this where apprentices come in handy!
Part of their job is to sort out the problems with time keeping and they get to see first hand the effect of screwing around at the machine has on job costings! Does rather drive home the fact that when on the machine, then need to keep their act together etc...

Hope this clarifies my position on this matter, if not, ask away!
Hopefully I will be able to assist you also!

I am now toying with the idea that I will write information to another file for information such as probed zero sets, so that in the event of having to re-run a program that can no longer be probed, I can look in the file and re-establish the same zeroset data. (the data may have been overwritten by the next job etc...) so you can imagine that it would be even more important for me to be able to write a time code to the file so that I can identify the correct zeroset in the file! Just have to remember to delete the file each day so that it does not become too large.

Cheers
Brian.

[slavetothemetal]

Brian,
After a bit of toying around, it seems to me that the internal clock variables are correct. By that I mean they are the same variables being used by MacMan. I checked all the variables, then I cycled the power on the machine, re-checked, and everything zeros out. This is the same way MacMan operates. So if you could get the operator to only use M00 and M01, you could simply write an M code macro and substitue that in your programs for M00 and M01. In your macro, record the time right before you read the M01 and add that variable each time to keep a running count of the cycle time and the stoppage time. The only issue is the Single Block button. There isn't a way to record this that I know of. Add this to what you have, and I think it will take care of everything you need. If only I could find out where all of the other information was stored, you wouldn't need to have the operator run anything else. On the zero set data, we actually write all of our data through a calculation program based on the probing we do, you should be able to write that stuff out no sweat. I have never used the write option, but couldn't you set the file name based on the part number? We have a folder on the network for our E control, so it could actually maintain a large amount of history before you needed to worry about it.

Bala,
As you read above, these variables all are in reference to the last power on of the machine. I think you will need something special to actually be able to see what time it is.

[broby]

Hi Kyle,
I really cannot see the point in putting together something that hangs off of the M00/M01 command!
I am chasing the TOTAL cycle time for the job, from the time the job went in to the machine to the time it comes out of the machine.
This is why I have a Timestart program and a TimeStop program.

As for writing the zeroset information to a network file, I do not believe that I can write directly to a network location from the machine. (will have to check to be certain, but I seem to recall trying this some time ago!)
I agree, writing information to a file straight after using the probe is probably the easiest method to use, rather than doing it at the end of the program.
Still need to give more thought to the whole idea.
Cheers
Brian.

[slavetothemetal]

Hi Brian,
What I meant by the M00/M01 statement was to account for stoppage of the job due to the operator hitting the op stop button. That would allow you to see how long the machine was in that condition for a part. Now looking at this, you could still access the MacMan variables and subtract them correct? If you used this in your time start and time stop programs, you could account for any reset time also.

[broby]

Hi Kyle,
Not really interested in finding out this stop time information, but I see where you are coming from.
Really only need the entire time in the machine.
Cheers
Brian.

[Bala]

Hi guys
lets say at 3pm how can I make the machine to automatically to run a different program or GOTO ABCD so it will skip every thing else and just go to that line ABCD, using just the internal clock.

Thanks
Bala

[broby]

Would have tosay that this type of process would be nigh on impossible to setup on a CNC mill.
Think about it, you are asking a process to abruptly change at a specific Time
This would entail that the machine have some kind of background program running all day that monitored the clock, then at the precise moment set, stop what is going on and run a different program alltogether!
This would entail a PLC type of process that be able to run in background mode.
About the closest to this I could think of is the "Calendar" process that allows you to "wake up" the controller at a a set time and warm up the machine.
Regards
Brian.

[slavetothemetal]

These are the types of items that make the P controls so attractive. Within reason you can have a process running in the background(in windows), as long as the specific item you are looking for is accessible. But switching at an exact moment in time does not sound very safe....

[broby]

Hmmm, Sounds like the P Controller is a very nice unit!
I believe we missed out on getting the new control by a matter of a few months when we ordered our MA600HB machining centre. Bummer!

Could imagine a truck load of grief interrupting a program running, or not, at a certain time of the day, based ONLY on the time of the day!

What are you trying to get working?
Brian.

[slavetothemetal]

Hey Brian,
Right now I am trying to get your original stuff to work, kind of. The standard MacMan is always in reference to the last power on, since the P controls are actually running Windows, I am trying to get a VBscript to record events from the machine side, then maybe further down the road, get something going to actually write to the system. Only issue is, I have to teach myself the laws of VBscripting first! And at around 15hrs/day here, not alot of time for "extra curricular" activities!

[broby]

Hey Kyle,
Don't enjoy yourself too much at my expense
Don't think I am going to the data I want from my E100M controller, can't see the reason why users would not be able to access the Date and Time variables
OH well, not a real show stopper at the end of the day anyway.
Cheers
Brian.

[slavetothemetal]

Hey Brian,
I love a challenge, and this seems to be a pretty large issue with all OSP users. I am fairly confident it can be done on a P control, just need to dig in and start getting my feet wet!

[broby]

Still picking the brick dust out of the front of the head, mind you the pieces are getting smaller as the patch on the wall gets smoother the more it gets used!
Would love to have a decent play around on a "P" control!
Have only seen one, and then I only got a peek at it for maybe 3 minutes.
The fact that I was drooling might have scared the hosts into moving me on! Bummer I say! Bummer!