Member Login
Search
Jump to a Date
Sponsored Communities
Cool stuff
Neat Stuff

Visit our shop for nerds in control lifestyle products.
Thermal Overload
The threads that wouldn't die...
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
Fortune
Everything should be built top-down, except the first time.
RSS Feed
www.control.com/rss/
To get a personalized feed, become a member at no cost.
I have an existing RSView application that I am trying to modify to pop up a verification screen when the operator attempts to start the line with the length counter > 0.
The application works flawlessly until there is an alarm condition that prevents the line from starting. In this case, the calling screen's object, a pushbutton, captures the cursor and that's all she wrote. The computer must be rebooted afterwards.
The pushbutton simply calls the VBA script with the VBAExec command. It also passes an argument so the routine knows which of two buttons were pressed.
The VBA application writes a value to a status register in the PLC depending on the operator response to the popup.
My question is: If the VBA app tried to write a value, does it continue to attempt to write that value until it can successfully read it back. What I think is happening is that the PLC program attempts to write to this same register when the alarm condition occurs. If this is so, then when the VBA app attempts to verify a successful write, it sees that the value is different and writes it again...and again.
Does this assessment sound plausible?
The application works flawlessly until there is an alarm condition that prevents the line from starting. In this case, the calling screen's object, a pushbutton, captures the cursor and that's all she wrote. The computer must be rebooted afterwards.
The pushbutton simply calls the VBA script with the VBAExec command. It also passes an argument so the routine knows which of two buttons were pressed.
The VBA application writes a value to a status register in the PLC depending on the operator response to the popup.
My question is: If the VBA app tried to write a value, does it continue to attempt to write that value until it can successfully read it back. What I think is happening is that the PLC program attempts to write to this same register when the alarm condition occurs. If this is so, then when the VBA app attempts to verify a successful write, it sees that the value is different and writes it again...and again.
Does this assessment sound plausible?
G'day Don,
I would be careful using VBA as a popup, it is not recommended in RSView32. I would use a RSView display/window as a popup instead. From memory if a VBA pop up occurs then RSView stops processing and waits for a result and the pop-up to close. If you can what you need without using VBA then do, either macros or events, and only use VBA if you need to do something that is not otherwise possible. What you have described should be easily done with standard RSView functions.
Cheers,
Trevor.
I would be careful using VBA as a popup, it is not recommended in RSView32. I would use a RSView display/window as a popup instead. From memory if a VBA pop up occurs then RSView stops processing and waits for a result and the pop-up to close. If you can what you need without using VBA then do, either macros or events, and only use VBA if you need to do something that is not otherwise possible. What you have described should be easily done with standard RSView functions.
Cheers,
Trevor.
Trevor,
I had read that somewhere. I only use the VBA script to initiate the pop up (a RSView screen). It is then supposed to terminate. The majority of the functionality is in RSView and not VBA.
VBA script below:
Public Sub productionStart(w_value)
'Subroutine implements poka yoke ensuring that operator is aware of length counter state
'and giving him an opportunity to reset the counter or proceed without resetting.
'local declarations
Dim ctr As Tag
'gets counter value from tag database
Set ctr = gTagDb.GetTag("counter")
'Determines counter state. If zero, exit sub after writing value to state register
'Value written to state register depends on which button was pushed
'Calling function, i.e. RSView passes w_value to subroutine
If ctr = 0 Then
If w_value = "16" Then
gTagDb.GetTag("state").Value = 16
End If
If w_value = "8" Then
gTagDb.GetTag("state").Value = 8
End If
End If
'If not zero, invokes RUSure graphic
If ctr <> 0 Then
gCommand.Execute "display rusure"
End If
End Sub
I had read that somewhere. I only use the VBA script to initiate the pop up (a RSView screen). It is then supposed to terminate. The majority of the functionality is in RSView and not VBA.
VBA script below:
Public Sub productionStart(w_value)
'Subroutine implements poka yoke ensuring that operator is aware of length counter state
'and giving him an opportunity to reset the counter or proceed without resetting.
'local declarations
Dim ctr As Tag
'gets counter value from tag database
Set ctr = gTagDb.GetTag("counter")
'Determines counter state. If zero, exit sub after writing value to state register
'Value written to state register depends on which button was pushed
'Calling function, i.e. RSView passes w_value to subroutine
If ctr = 0 Then
If w_value = "16" Then
gTagDb.GetTag("state").Value = 16
End If
If w_value = "8" Then
gTagDb.GetTag("state").Value = 8
End If
End If
'If not zero, invokes RUSure graphic
If ctr <> 0 Then
gCommand.Execute "display rusure"
End If
End Sub
It is all about focus. The alarm changes focus!
.focus
.focus
From Control Engineering magazine...
Related articles from Control
Engineering magazine- Pushbuttons, in 3 sizes, change colors
- Arctic HMI: Human-machine interface performs in harsh Arctic Circle conditions
- From IT integration to panel building, one mine at a time
- Gantry-Style Automated Accumulation
- PACMotion certified in compliance with PLCopen for motion control standard
- Packagers suggest integration improvements
- Integrators play central role in packaging automation
- Rockwell Automation introduces virtual design and production software utility
Above articles copyright 2009 Reed Business Information.
Subject to its Terms of Use.
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2009 Control Technology Corporation. All rights reserved.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Patronize our advertisers!




