PMersault

MrPLC Member
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

1 Neutral

About PMersault

  • Rank
    Sparky

Profile Information

  • Gender Male
  • Country United States

Recent Profile Visitors

2605 profile views
  1. It may help to note that a View32 project can be imported into ViewSE.
  2. FTView SE 6.10 64-Bit System

    Clients won't care about the server's platform - XP 32-bit would be fine.
  3. Any FTView Guru's Around?

    As an alternative to the other suggestions and VBA, you might investigate the multistate indicator instead of using string displays. You can embed the tag in the indicator's display, then use the combo box's value to change the indicator's state (an HMI memory tag would suffice for this.)
  4. What's in there that you're looking to update? I'm assuming you mean that something is programmatically pushing data into the sheet?
  5. VBA code resides at the display level. Drop a new command button (the gray one that can be scripted) onto a screen, then right-click and select VBA code. You'll be directed to that button's code automatically, which is currently empty. It will look like this: Private Sub Button1_Released() End Sub Before coding, you need to reference the MSExcel object model: Tools -> References Mcirosoft Excel ## Object Library (## dependent upon version) Now replace the existing code for the button with this: Private Sub Button1_Released() Excel.Application.Workbooks.Open "c:\excel.xlsx" Excel.Application.Visible = True End Sub This will open and show MSExcel with the file open. Note a few things: The excel thread will stay open until the user closes the window (you can see it as EXCEL.EXE in task manager.) I cannot remember if this will keep the VBA thread active as well, as I usually don't expose the excel GUI to the operator. If you're planning on doing any kind of programmatic manipulation, I recommend instancing the application and workbook objects, then destroying upon completion. Finally, note that the VBA code in ViewSE runs client-side, not server-side. This means that the Excel file will need to be on each client; it can't just exist at the server level unless you're mapping a drive.
  6. RSViewSE and FactoryTalk View SE are essentially the same product at different versions. I can't recall the timeline, but maybe around 5 years ago Rockwell changed most of their "RS" naming to "FactoryTalk." Another example would be RSBatch = FactoryTalk Batch. So the concepts in the knowbase article below extend to your version as well, Rockwell simply hasn't updated it in a while. The second option is the most robust, and what I would recommend. Of course, it also requires the most administration on your end. A subset of this option would be to programatically extend the client frame, then allow your users to move the windows around on their own, as opposed to 'hard coding' their location in the display properties. I attached the referenced ZIP here in case it helps. Multiple Monitor Code Sample.zip
  7. Quite a bit to copy in, but we'll see if it comes through: Application Scenarios: There are generally 3 application scenarios for using multiple monitors with the RSView SE Client: 1) The "SE Multiple Client": This scenario is ideal for HMI "power operators" (and experienced Windows users) who need to see multiple HMI displays simultaneously. It is accomplished by simply running multiple sessions of the RSView SE client and placing them on separate monitors. Typically, the operator would have a shortcut to a pre-configured RSView SE Client on the desktop of the primary monitor. The operator would launch the first session of the client and simply relocate it to a secondary monitor. Next, the operator would return to the primary monitor and launch an additional session of the RSView SE Client that would remain on the primary monitor (or be placed on a different secondary monitor, etc.). This is the recommend scenario for most customers due to the relative ease of implementation. Advantages: no custom HMI project coding is required, allowing a mixture of both single and multiple display SE Clients (with a variety of resolutions) throughout the system no additional SE Client activations are required at the client computer these are 3 autonomous sessions of the SE client. If you are not using FactoryTalk Security's single sign-on feature, you could logon to both sessions as the same user, or logon to session #1 as user "X" and session #2 as user "Y", etc. Disadvantages additional hardware resources are required at the client computer requires that the HMI operator have knowledge of managing multiple applications in Windows requires that the SE Client file (.cli) be configured to "Show title bar", "Show system menu and close button" and "Show Min/Max buttons" so that you can drag and drop the program to another monitor records in the Diagnostics List (if displayed) are not unique to the individual client session (they are common for the client computer) allows the HMI operator to get to the Windows desktop, Start Menu, Command Prompt, etc. (Note: this can be mitigated using Group Policy to "lock down" the desktop environment) 2) The "SE Custom Client": This scenario is ideal for HMI "power operators" (but inexperienced Windows users) who need to see multiple HMI displays simultaneously. It uses only 1 session of the SE Client, however it expands that session across the larger "virtual desktop" created by adding additional monitors. For example, consider an SE application with 2 areas ('East' and 'West') where every operator station has 2 monitors (1 for the 'East' displays and 1 for the 'West' displays). In this example, the HMI developer would use X,Y coordinates to configure all of the 'East' displays for one monitor and all of the 'West' displays for the other monitor. Advantages: no additional hardware resources are required at the client computer no additional SE Client activations are required at the client computer. requires no HMI operator knowledge of managing multiple applications in Windows because typically only the SE Client is running allows you to "lock down" the desktop environment and allow the HMI operator to only use the RSView SE client Disadvantages all SE Clients in the system may require the same multiple monitor configuration (i.e., orientation and resolution) or else the SE graphic displays may not display properly requires HMI project custom coding to control the position of the displays making the project potentially more difficult to troubleshoot and maintain Implementation of this scenario requires VBA programming that increases the size of the SE Client "container" window (see Answer ID 24607 - Controlling the size of the client container window). For example, when using 2 monitors side-by-side (where both are configured for a resolution of 1024 x 768), you would typically create a client container window of 2054 x 774 (the additional 6 pixels allow for a 6 pixel frame around the container). This container would then allow two ~1024 x ~768 displays to exist side-by-side inside 1 session of the SE client. Note: To familiarize yourself with the 'SE Client Container' settings on your multiple monitor system from within RSView SE, unzip the attached Multiple Monitor Code Sample.Zip and follow the instructions in the ReadMe.txt file. When using this scenario, the following RSView SE Display Settings are typically recommended: Display Type 'On Top' (vs. 'Overlay' or 'Replace'). 'Size to Main Window in Runtime' unchecked (if checked, the display will occupy the complete SE Client container) Click the Help button (or F1) in the Display Settings dialog for more information on these settings. It should be noted that using the 'On Top' display setting may lead to many unnecessary displays being left open that will consume system resources and also maintain many data connections to the processors both of which may affect your application performance. Your application must make use of the abort command to efficiently manage the open displays. When using this scenario, the following RSView SE Client (.cli) settings are typically recommended: Show Title Bar unchecked (if checked, the Title Bar will extend across the virtual desktop) Maximize window unchecked (if checked, the display will only occupy 1 monitor) Show Diagnostics List unchecked (if checked, the Diagnostics List will extend across the virtual desktop, but it can be undocked) Click the Help button (or F1) in the RSView SE Client wizard for more information on these settings. A slightly more complex version of this scenario would allow the operator to choose which monitor a graphic will be displayed on. For example, a "Navigation Menu" graphic that contains buttons that represent the available monitors (e.g., "left", "center" and "right") in addition to the available graphic displays. The HMI operator must click the desired graphic display and the desired monitor. This technique uses the native RSView SE display command with display positioning parameters. 3) The "SE Virtual Display Client": This scenario creates 1 large "virtual display" runtime window spread across multiple monitors, where each video adapter's display area is part of a single desktop. The size of the desktop is determined by the size and the arrangement of individual display areas, which in reality reflects the arrangement of the monitors. Using this scenario is virtually identical to the "SE Custom Client", except the SE Client container size would typically be much larger and the displays would typically all have the setting 'Size to Main Window in Runtime' checked. Advantages: same as the SE Custom Client provides a very large "virtual monitor" for a central control room or command center Disadvantages the loss of single monitor detracts from the large "virtual monitor" Note: To familiarize yourself with the 'SE Client Container' settings on your multiple monitor system from within RSView SE, unzip the attached Multiple Monitor Code Sample.Zip and follow the instructions in the ReadMe.txt file. A 4th application scenario is also possible, the "Super Client" or "Engineering Workstation". This scenario is identical to the "SE Multiple Client" except it is typically used by HMI/PLC developers and maintenance engineers. It allows the user to run multiple software programs simultaneously (e.g., Studio, RSLogix, the SE Client), where each program occupies its own monitor. Using this scenario is very straightforward, you simply launch the programs and relocate them on their own individual monitor. Note: A maximized program will not relocate from one monitor to the next, you must 'Restore Down' the program to relocate it (using drag & drop) on another monitor.
  8. There looks to be a good deal of information about this topic here: http://rockwellautomation.custhelp.com/app/answers/detail/a_id/34321.
  9. Check your schedule configuration. PVPs need to have the config file specified at the asset level in the tree, as well as their specific MER file specified in the schedule. Select the schedule, then in the pane where you see the status select the PVP itself (as in your second screenshot.) In the right pane, you should see Asset specific properties -> Source File Name. You'll need to fill in the specific MER file you want it to back up here, along with the file extension (e.g., MyFile.MER)
  10. I'd recommend using parameters as well, but using the /t switch. /t is a direct tag name pass to a parameter, as opposed to use a /p which would pass in the parameter file. You won't need to create multiple files in this instance. For example, a simple test application: Main Screen: 32 "Edit Tag" buttons corresponding to TagName1 - TagName32 Pop-up screen: Numeric entry Each Main Screen edit button will use the same command, varying only by the tag in question. e.g., Edit Tag #11 would be "display PopUp /tTagName11" The Pop-up screen's numeric entry would simply point at #1. ________ A twist comes in with your goal of having the save/cancel functionality. In this case, I would personally create a 'PlaceholderTag' as a memory tag, and point the numeric input there. I'd throw a numeric display above that to show the current value of the actual tag (linked to #1.) Now my pop-up has the current value (#1), the proposed value (PlaceholderTag), save button, and cancel button. Cancel button merely Abort me's. Save button also abort me's to clear the screen, but prior to that it writes the value from PlaceholderTag to #1 - "Set #1 PlaceholderTag". So your save button command would look like: set #1 PlaceholderTag abort me Finally, it would probably be nice if the PlaceholderTag reflected the real tag's current value upon pop-up. To accomplish this, go into the Pop-up's display settings, Behavior tab. Under Startup put in "Set PlaceholderTag #1." This will write the real tag's value to the PlaceholderTag when the pop-up is opened. Best of luck...
  11. Gateway is considered the top of the line, so you got the 'superior' product. They're mostly the same except Gateway adds the ability to act sort of like a router. As you're probably aware, Professional gives you the OPC server ability over Linx Lite. Gateway also acts as an OPC server, but it adds the option to reference it from other Linx Classic servers. From a separate Linx instance, you can point at the Linx Gateway and reference its drivers (for instance, if your separate Linx box doesn't have a CNET card, but the Gateway does, you could use the Gateway to gather the CNET information and pass it through the non-CNET box.)
  12. Just to clarify, you can select both HMI and PLC tags for a datalog. Right-click in the tag browser and select "Show Server Names" - that'll show the data server for PLC and the HMI server for HMI tags. Sounds like the above posted ActiveX might be a better solution, though.
  13. Depending on how many HMI tags you've got, you could put them into a test datalog model. When the model's turned on, it should report which tags it can't communicate with. Turn it back off, repair any bad connections. I think you can have a max of 10,000 tags per model, probably just create more models if need be.
  14. RSview32 help!

    Take a look at using an Event (under Logic and Control) to issue a Display command when the alarmed tag goes high. Be sure to turn the Event file on (like alarming) when you run the project.
  15. No "manual" way to program, and on the PV+ side (as opposed to the distributed SCADA side) no VBA scripting available either. I can't think of a way to push values into empty buttons from the controller, but would a numeric input work? This would allow you to enter/display the value directly, then use a button if you want to force the operator to "accept" the value (i.e., write the value down to a tag in the controller, then use the button to toggle a bit high on the rung moving the tag value to the motor.)