Stopwatch in VisiLogic

[lfreeman4511]

Has anyone created a stopwatch in Visilogic?  Here's what I am trying to achieve:

Machine jams,

Stopwatch starts,

Operator clears jam,

Stopwatch time is recorded in bit,

Stopwatch Resets

 

Right now I am using Accumulating Timers to simulate, then calculate this during an entire 12 hour shift, but would like to have something appear on the display that resembles a stopwatch with the jam message. 

[Joe Tauser]

Timers are good until you need to extract information, like machine down time.  Then it's time to make your own so you can do whatever you want with it.

Unitronics doesn't have a built in stopwatch picture, so I Googled "stopwatch image" so I had something to put on the screen.  Then I put my time calculation registers on top of it.

Take a look at the attached program.

Joe T.

Stopwatch.vlp

[lfreeman4511]

That's genius.  I hadn't thought about going that route.  Thanks!

[John_R]

That's interesting Joe,

I never paid attention to SB13,  I've always just used a Positive Transition Contact with SB3 when I roll my own timers....

Also, did you do this on the new "wide screen" version? it opens  on my older version, but net 3 is clipped off.

Something I guess we gotta watch out for as we transition into the wide screen format....

 

JohnR

[Flex727]

10 hours ago, Joe Tauser said:

Take a look at the attached program.

@Joe Tauser, did you write that in the newest version of VisiLogic? I haven't installed it yet, but I was able to open the project in 9.8.31. Unfortunately, the wider ladder rungs did bad things - they try to go off screen and can't be accessed. Unitronics needs to prevent 9.8.64 projects from being opened in previous versions.

[Joe Tauser]

I did use 9.8.64.  I'll inform the Creators about the reverse compatibility issue.

Joe T.

[Ausman]

Nice and neat, Joe.  Ditto on the screen problem.

But it has also jogged a query in my brain.    I often do a direct compare for a time result, and wonder whether using a FB is easier or harder on the system.  There are a myriad other things I use that I can say the same for.  Is there somewhere that I can find a list of scan times applicable for any element or FB?  I've never stumbled on it.  Even an excel sheet or similar from the Creators would be good.

cheers,

Aus

[Flex727]

On 7/20/2017 at 10:39 AM, Joe Tauser said:

I did use 9.8.64.  I'll inform the Creators about the reverse compatibility issue.

What was the response? I just tried to open another project created in 9.8.64 and it wouldn't open in 9.8.31 (notified me that it was created with database 153 vs database 152 for 9.8.31). I see that the VisiLogic version available online still says 9.8.64. I tried to open @Joe Tauser's Stopwatch program again with 9.8.31 and it opens fine. Are there now 2 versions of VisiLogic 9.8.64 floating around, one using database 152 and one using database 153?

[EMiller233]

On 8/28/2017 at 9:38 AM, Flex727 said:

What was the response? I just tried to open another project created in 9.8.64 and it wouldn't open in 9.8.31 (notified me that it was created with database 153 vs database 152 for 9.8.31). I see that the VisiLogic version available online still says 9.8.64. I tried to open @Joe Tauser's Stopwatch program again with 9.8.31 and it opens fine. Are there now 2 versions of VisiLogic 9.8.64 floating around, one using database 152 and one using database 153?

anyone know if this has ever been resolved?  it is now 05/2018 and i just received this error opening up an old project

[Flex727]

On 5/11/2018 at 2:15 PM, EMiller233 said:

anyone know if this has ever been resolved?  it is now 05/2018 and i just received this error opening up an old project

I don't understand your question. The problem was that the error DIDN'T occur when it should have. Anytime you open a project that was created with an older version of VisiLogic, the software will notify you of that. That is what it's supposed to do. You can either proceed opening the file in the newer version or you can use Version Swapper to downgrade your VisiLogic to the older version and edit the project with that version.

[Oath]

I know this is an older post, but I have added a feature very similar to this as a Hobbs Meter to one of our scale programs, using an input to determine when a machine's run circuit is engaged.

I'm curious though on how precise the second pulse is, as we've gained about 6 minutes a week from our reference Hobbs meter during testing. Is there any documentation on the overall precision of the second pulse, particularly for the V570? In all honesty, I suspect our reference Hobbs meter is probably running a touch slow, but I haven't had the patience or time to stand out at the machine with a stopwatch for a week to find out!

[Joe Tauser]

13 minutes ago, Oath said:

Is there any documentation on the overall precision of the second pulse,

I'd reach out to support@unitronics.com for this one.  I'm pretty sure the the one second pulse isn't running off a crystal oscillator.  Neither is the real time clock.  I tell people that the RTC can drift one minute per month.

What is the accuracy of the Hobbs meter?

You could be running into a cumulative scan time issue.  The scan time of a V570 is typically 5 - 10 ms, and if you're accumulating seconds based on the the one second pulse during the scan you could be off by some amount for each count.  If the time accumulator is running for a whole week then you're talking about 604,800 seconds.  Six minutes is 360 seconds, so the error is 0.06%.  Over a year you could be off by five hours.  

Does that error matter?

I would try an experiment using accumulating TA timers, which are tied to the internal clock and run independently  of the scan.  Use whatever logic you have enabling the one second pulse and run a 1 hour TA timer.  When it times out increment a register to count hours and reset it.  At the end of the week you can look at the hour count register and whatever the current value of the TA accumulator is to compare to your Hobbs value.

Joe T.

[Oath]

The Hobbs meter we're referencing is expected to be within 0.025% for accuracy, which I'm betting is a contributing factor (though maybe not a particularly large one).

For this particular instance, we've only had the test machine running around 10-14 hours a day during weekdays, which would suggest a higher error rate. However, for what we are intending on using this data for, the actual drift per-shift is below the resolution we're using for the calculations anyhow (we only look at hours and tenth-hours currently), so the only way this would be an issue is if we ended up using it for long-term maintenance timing (1000 hour maintenances or something similar), but even that amount of imprecision might be doable. Since the RTC is pretty accurate, we might be able to just capture the RTC data on a machine start and stop and do math from that or something similar, if we need more precision.

As for testing with accumulating TA timers, I'll give that a go! I hadn't thought to use that originally, so it might end up being a closer match to our current Hobbs meter.

Thanks for your reply Joe!

[Ausman]

I also suggest that you take a look at deriving your time by using a 1.25 or 2.5mS Interrupt Routine.  Bearing in mind all of Joe's comments, using the Interrupt might  give you better accuracy.  In some ways it is likely easier to implement, too. 

Look up Interrupt in the Help index, and then go to Interrupt Routines.  You could easily implement both measures concurrently to let the PLC show it's own comparisons over a week or so.  I suspect that you will find the Interrupt will be better accuracy, but it would be interesting to know the result.

cheers, Aus

[AlexUT]

Hello all,

- Scan time is not precise.

- Timer is not precise.

- Quarz in PLC is not precise.

Nothing is precise...

Especially when PLC internal temperature is changed and dependent of:

- Season;

- Day/night temperature variation;

- PLC load variation;

- etc.

Additional to Interrupts you can use following existing incrementing counters:

As well, you can use "RTC to UTC" and calculate difference in seconds. *Has RTC precision, not PLC Quartz precision. 1 sec step.

.

If quartz precision is "low" for you - use time correction by use of Time Servers. *1 sec precision.

 

If you require mich more precision - may be you have to use Cesium clock, which will add an additional price to project, as it require an additional interface as well.

Summary:

Be realistic in your requirements.