Local time not correct

mk42 said:

I think the internal clock is run by some capacitor that holds its charge for X amount of time (a few weeks?) while the PLC is off. It will go back to default once the cap is drained. How long are the PLCs off for?

Also, I thought the 1200's and 1500's defaulted to a more recent time (2011 or something?) than 1970, could be wrong tho. I think 1970 is the value of an empty DATETIME datatype. If all your reads are coming back as 1970 Jan 1 0 sec, you might just be reading/writing the wrong tags.

If it's really resetting back to 1970 each power cycle, you might try utilizing an NTP server, or sync back to a GPS clock.

Edit: another thought: just because the take time from PG/PC box is checked, doesn't mean it automatically happens. You still need to press the button to set the time in the PLC. What time is the PLC telling you it is set to on that screen?

Click to expand...

mk42 said:

I think the internal clock is run by some capacitor that holds its charge for X amount of time (a few weeks?) while the PLC is off. It will go back to default once the cap is drained. How long are the PLCs off for?

Also, I thought the 1200's and 1500's defaulted to a more recent time (2011 or something?) than 1970, could be wrong tho. I think 1970 is the value of an empty DATETIME datatype. If all your reads are coming back as 1970 Jan 1 0 sec, you might just be reading/writing the wrong tags.

If it's really resetting back to 1970 each power cycle, you might try utilizing an NTP server, or sync back to a GPS clock.

Edit: another thought: just because the take time from PG/PC box is checked, doesn't mean it automatically happens. You still need to press the button to set the time in the PLC. What time is the PLC telling you it is set to on that screen?

Click to expand...

Jozir said:

https://ibb.co/nPhnNo

currently have this. Time still remains 1970 hmm

Click to expand...

mk42 said:

Those are just the start values, ie what the tag is initialized to when the PLC starts up. You'd need to monitor the tags, blocks, or create a watch table to find out the actual value.

Click to expand...

Jozir said:

I can't monitor an interrupt since it's only executed one cycle. I tested it this morning but the 'Tijd_nano' remained 0.

Click to expand...

mk42 said:

Fair. For now, try to do something simple. Do you know the interrupts are being called?

I'd recommend testing two things:

1) move the code from interrupt 0.0 and 0.1 into your Main OB, and then trigger the calls on the value of the appropriate input. That way, you can test the IO and the time code. The times won't be as accurate, but you should get SOMETHING. Note that it may require you to trigger the inputs with a finger or roll the ball slowly, instead of properly rolling the ball at speed.

2) set a new tag in each interrupt that says it has been executed. you can reset it manually, from a watch table.

When you test the code, you should be able to see if the inputs trigger at all, and if so, if the time code seems to do anything. You should also find out if the interrupts are triggering at all.

Click to expand...

Jozir said:

When I cross my sensor with my hand I see 2 inputs (1 normal 1 configured as interrupt) flashing on the plc, same for my other sensors. So the interrupt definitely triggers.
Btw what do you mean with setting a tag that shows whether or not it has been executed?

Also good thinking to put the code in my main, I'll try that aswell.

Click to expand...

mk42 said:

If you see the LED on the input turn on, that is different than the interrupt triggering. You need to actively enable the interrupts in the device properties, there are a few settings, and it could easily be misconfigured.

What I'm suggesting to do in the interrupt is to add a rung with just a SET coil (not a regular coil). Put a new tag on it, named something like "interrupt 0.0 executed". In a watch table, monitor that tag (should be false to start), then trip the input (bit should go true). You can then reset it from the watch table if you want to, or just delete it entirely.

Click to expand...

cardosocea said:

Your screenshot shows Channel 1 and 2 on the inputs, but originally you said it was 0.0 and 0.1. Is this correct?



Also, the T_DIFF instructions mentions this:



If the result of the subtraction is outside the TIME range, the result is set to "0" (0:00) and the enable output ENO = "0".


Do you see the return val of the instruction to see if all is ok?



I really don't know the TIME range... but if you're counting in nanoseconds it can't be much.

Click to expand...

Real time clock retention time 20 days typ./12 days min. at 40 °C (maintenance-free Super Capacitor)

Click to expand...

What I want to do:
1)Read local time when signal on I0.0 (using RD_LOC_T)
2)Read local time again when signal on I0.1 ^^
3)Divide those and put in a variable ( using T_DIFF)
4)Use math functions to get from nano seconds to seconds.

This is not possible when the local time is not correctly.

Click to expand...

#Previous_Time:= #Current_Time;
// Transfer Current time to previous time
#"Cycle_Time_n-1":= #Cycle_Time;
// Get the new Current Time
#sPIDCalc."RD-Sys_T_return":= RD_SYS_T(#Current_Time);
// Subtract Current from Previous to get Time in ms
#Cycle_Time:= T_DIFF(IN1:=#Current_Time, IN2:=#Previous_Time);
// Convert to Real and divide by 1000 to get time in seconds
 #sPIDCalc.Time_in_Secs:= DINT_TO_REAL(TIME_TO_DINT(#Cycle_Time))/1000;