While the provided migration tools are very helpful to make the process as painless as possible, there are still some things that can accidentally trip you up. Here are some tips to keep in mind when performing a conversion to GENESIS64. 

Tip 1: Remember to include all of your data 

When using the GENESIS32 Exporter tool to export your current data, you need to make sure that everything you want to migrate is included in your export project. GENESIS32 was designed as a very modular system: which means there are multiple components that all need to be included and no centralized place to manage them.

While it is easy to remember all your GraphWorX files, you also need to include files such as your AlarmWorX server database. The exporter tool will convert them into an XML format that allows them to be easily imported into GENESIS64. 

If you do not have access to the database files, you can also work with a CSV export. These will not be automatically converted for you, but you can get them to work with GENESIS64 through a little manipulation. If you do so, avoid using Excel to modify the CSV file, as it is possible for the format to get altered in a way that makes it incompatible. 

Tip 2: Set the appropriate options when importing 

In the ConverterWorX Importer utility of GENESIS64, there are many options available to customize how objects are migrated. While the defaults are reasonable, it is a good idea to go through and make sure the options that make sense for your application are checked. The options that are shown are context-sensitive, so, if you want to modify the options for AlarmWorX import, you will need to select an AlarmWorX object. 

Here are a few settings that I often change:

Translate OPC DA tagnames to OPC UA tagnames 

Chances are, if you are converting from GENESIS32, your tags are using OPC DA. If you plan to continue using OPC DA in your new GENESIS64 application, make sure to uncheck this box; however, you will still have to go through and append “.Value” to your OPC DA tags to make them resolve correctly (hint: you can open your .gdfx file in a text editor and do this a bit faster). 

Translate object name to valid Gwx64 name 

It is a good idea to check this option to make sure your imported objects do not end up with an invalid name. 

Disable using classic border from Gen32 

The Classic Border object was a useful way to organize objects in GENESIS32; however, I find that grouping is much simpler in GENESIS64, and I prefer to remove Classic Border objects by checking this box. 

Convert ActiveX Controls 

You have the option to either try to convert any ActiveX controls (such as alarm viewers, grid viewers, etc.) to the .NET equivalent used in GENESIS64, or to replace them with placeholders.

Replacing with placeholders will place a red rectangle with text indicating what type of control it is a placeholder for. The placeholder option is good if you plan to revise the controls as part of the migration; however, if you are planning to keep everything as similar as possible, the .NET controls will do a lot of the work for you.

In my experience, there is sometimes a little cleaning up of the replaced controls required, but it still saves more time than configuring it from scratch. No matter which approach, I always recommend looking at your GENESIS32 and GENESIS64 configurations for these controls side by side, so you can verify that everything will be as similar as possible. 

Once you have your options set the way you want, go ahead and start the import, but read the next tip before you call it a day. 

Tip 3: Save your conversion log 

The log generated by ConverterWorX is very helpful. Whenever you are doing an import, you should always review the log at the end and keep an eye out for any errors or warnings. Anything that could not be converted (such as scripts) will be noted. This makes the log a great reference for making sure you go through and migrate everything manually.

There is a handy option to save the log as a CSV file for later reference. I like to put the log in version control with the other files so that I can easily pull it up when working through the migration process. You can even open the log in ConverterWorX to get the nice filtering options that it has. 

Tip 4: Rewrite your scripts 

One of the biggest challenges of migrating to GENESIS64 is that there is no automatic migration of scripts. GENESIS32 used two languages for scripting: VBScript and VBA. GENESIS64, on the other hand, uses JScript .NET. The syntax and structure of these languages are quite different, although VBScript is a little closer and can sometimes be quickly adapted with a little find/replace magic. Most of the time, though, it makes sense to rewrite the scripts from scratch.

While JScript.NET is not a very prevalent language, it shares many similarities with other .NET languages such as C#. The documentation from Microsoft can be found here, and Iconics has some additional documentation and examples on their site, including the API documentation for the Iconics-specific libraries. The API documentation can also be referenced from within the code editor. 

While it would be impossible to cover every aspect of scripting without writing a medium-sized book, here are a few tips that I use in many projects: 

Adding References 

Any other .NET-compatible code can be used inside your scripts if they are compiled into a DLL file. Iconics includes several for you to use that are required if you want to access libraries such as those for working with grid controls. You can find these in the GENESIS64 installation folder, inside the Components sub-folder. 

Save Scripts in JS Files 

You can save your developed scripts in files that allow them to be reused later. This can be helpful for developing a library of utility functions that get used on multiple projects. The Import function allows these scripts to be imported back into Iconics. Unfortunately, there is no Export function, so you will need to copy/paste your script into a text editor and save it as a .js file. 

Enable IntelliSense 

The IntelliSense feature supports auto-completion of functions and shows helpful documentation. It can be enabled from the toolbar at the top of the script editor. Sometimes it is a little buggy and will not show up properly, but usually that is due to a syntax error in the script causing it to be interpreted incorrectly. 

Tip 5: Throw away your scripts 

The easiest way to write scripts is to not have to! GENESIS64 has more powerful out of the box functionality than GENESIS32, and you can often avoid writing scripts by just taking advantage of its features. Here are a few things that can be replicated without using scripts: 

1. Writing values to a SQL database. You can instead create a Data Manipulator in Workbench, and link that to a button or other Pick action. 

2. Manipulating properties of screen objects. Using the new localsim:property:propertyPath syntax, simple properties such as opacity can be modified from any dynamic. See the Set Object Properties Without Scripting section of the documentation for details. 

3. Modifying aliases. The Set Local Aliases and Set Global Aliases commands for Pick actions support this natively. As a bonus, the built-in Data Explorer allows you to just pick the alias(es) you want to modify, and GraphWorX will take care of the rest. 

Tip 6: Minimize expressions 

To be clear, there is nothing inherently wrong with expressions. They are a handy way to parse and manipulate data in a single data point; however, the syntax for expressions can be overly verbose, and they are more difficult to troubleshoot. I try to avoid using them when I can, and GENESIS64 includes some new tools that can replace traditional expressions. Let’s say I have an object that I want to hide when a tag is between two values. With an expression, the data source of my Hide animation looks like this: 

Hope you have a big enough monitor, otherwise scrolling through the expression is even more tedious! Let’s replace it using the new range functionality of animations. 

Now the LowLimit and HighLimit properties work as my lower and upper bounds on the data source. These can even be linked to other tags. It makes the dynamic much more readable, and the error messages you get at runtime will be much clearer. 

Tip 7: Take advantage of Smart Symbols 

One of the best features introduced in GENESIS64 is Smart Symbols. Smart Symbols allow you to create reusable graphics that can be embedded throughout your project. If you are used to creating symbols in GENESIS32, Smart Symbols will be intuitive and make your life even easier.

I’ve previously written about how to create and use Smart Symbols, so check that out when you’re getting started with your migration. Although it will take extra time, creating Smart Symbols will pay dividends when it comes time to expand or update your system in the future. 

If you follow these tips during your migration, you will end up with a quick and easy process, as well as a GENESIS64 system that takes advantage of its new features and technologies. If you run into any problems along the way, do not hesitate to reach out; DMC provides services for both GENESIS32 and GENESIS64 platforms. 

Learn more about DMC’s Iconics Programming expertise and contact us today for your next project. 

The post Iconics GENESIS32 Upgrade Tips and Tricks appeared first on DMC, Inc..

What is a Smart Symbol?

A Smart Symbol is essentially a group of objects that have their properties and data exposed at the group level. Creating a Smart Symbol is extremely simple: select an existing group of objects, right click, and choose Convert to Smart Symbol.

You will then be given two options: Expose data sources as Smart Properties and Optimize hierarchical data sources. The first option will take any data sources in the objects that have already been configured, and create Smart Properties from them. The second will attempt to organize existing data sources to make use of the new Smart Properties. For a brand new group of objects, there will be no effect. For objects that have data sources, you can use whatever options make sense.

The next window that will come up is the editor for Smart Properties. Smart Properties are at the core of Smart Symbols; they allow you to define properties that can be inherited by any objects that are a part of the Smart Symbol. These will be discussed in detail in the next section; you can leave them blank for now. Let’s look at what changed on the Smart Symbol’s properties.

Using Shared Keywords

Notice that there is a new Smart Properties group where I’ve defined a blank Smart Property named TestSmartProperty. A new field has also been added to the Common group, ShareKeyword. The Shared Keyword allows you to define a template for your Smart Symbol. In this example, I’ve used the ShareKeyword MyValve. I can create other Smart Symbols and assign them the same Shared Keyword. Later, if I need to change some aspect of the valve Smart Symbol, I can push the changes to every instance of a Smart Symbol with the same Shared Keyword.

To do this, select the Smart Symbol that you want to replicate. On the ribbon, go to the Dynamics tab and click Update Shared. It will then give you several options to configure how other Smart Symbols will be updated.

On the left, you can select the scope used to find and update other Smart Symbols. You can choose to limit yourself to your currently selected objects, the current layer or group, the entire current display, or you can select several GraphWorx64 files to update at once. For large projects, a good practice to use is to have a separate GraphWorx64 file that contains master copies of all your Smart Symbols, and then to select all your project files to make sure every symbol gets updated.

On the right, you can choose what properties of the Smart Symbols will not be changed in the update. Any item checked will keep its current value after the update. You can then click Update All to immediately update all the linked Smart Symbols, or Ask Update, which will have you individually confirm each update. As you can see, Shared Keywords make managing large projects with repeated icons a much easier task.

Using Smart Properties

Now let’s talk about the Smart Properties feature of the Smart Symbols. Smart Properties allow you to define a value that can be referenced by any member of the group. These properties can take many forms. You can define Smart Properties as strings, colors, fonts, and many more options.

To create Smart Properties, right click the Smart Symbol or the Smart Properties section on the Properties tab and choose Edit Smart Properties. You can then add and remove Smart Properties as well as edit their name, their data type, and their default value.

You can also use existing properties to create a Smart Property by right clicking and selecting Add To Smart Properties and providing a name for the property. Properties that are linked to a Smart Property are denoted by a small yellow symbol.

If you have a property that you would like to link to an existing Smart Property, you can right click it and select Smart Binding Editor. This editor gives you several powerful tools for creating links to Smart Properties. Many different properties are valid targets for binding; you can use a data source for a dynamic event, the fill color of an object, the font size of a text label, and much more.

On the left, the available Smart Properties will be listed. Checking the box at the bottom will limit the selection to Smart Properties with compatible types. This is checked by default, so be sure to uncheck it if you don’t see a Smart Property you need. You can double click a Smart Property to add it to the cursor position in the editor. On the right are shortcuts for using built-in functions and operators, such as cosine, equality, OR, and string formatting.

Using these functions in conjunction with Smart Properties allows you flexibility in how the member objects interact with each other and respond to system data. Some examples of using these features are:

• Several objects are linked to an integer Smart Property. Different objects can be shown or hidden, depending on the integer value
• An object changes its fill color based on what combination of 3 different boolean values are true
• A Smart Property is linked to a word value, and its objects each use 1 bit to determine if they are enabled

Using Smart Properties in Smart Symbols also makes reusing symbols simpler. You can define the member objects to respond the same way to given data, and then link the data source to a Smart Property so that each symbol has a unique data source. If you later need to change the behavior of member objects, you can use the Shared Keyword to push the changes to all instances while leaving the Smart Property data source unchanged. Next time you are working in GraphWorX64, try creating some Smart Symbols and see how much time they can save during development.

Learn more about DMC’s Iconics Programming expertise.

The post Using Smart Symbols in Iconics GraphWorx64 appeared first on DMC, Inc..

One of the features that enables fast development is the ability to use data from a SQL server database, a standard in many industries. Genesis64 uses an application called GridWorX64 Server to query data and store them in datasources which can then be accessed by grids, charts, labels, buttons, etc. in GraphWorX64. One may think of these datasources as being similar to SQL views. Read more about datasources in Genesis64 in the next blog post: Refreshing Datasources in Iconics Genesis64 HMI/SCADA Development Software.

Fast development is also facilitated by the numerous built-in Windows Forms and WPF elements in GraphWorX that can be tied to datasources in GridWorX Server quite easily. While the variety of elements that are available is substantial for basic tasks, more advanced tasks, such as processing user input and running stored procedures to change data in SQL, requires custom scripts. Custom scripting can be very powerful in Genesis64, but it can easily become cumbersome to maintain if care is not taken during development. The scripting environment that is available is Jscript.NET; however, occasionally you may run into certain properties or methods that are not available in this environment, but are documented on MSDN’s website.

In the application that we developed, scripting was extensively used to manage the front-end as well as initiate actions on the database from the user interface. For example, scripts were used to run stored procedures that created a new recipe, edited an existed recipe, deleted a recipe, etc. The inverse of this is also true in cases where the database had to be queried to show the user options for input: an example is the population of dropdown lists from which the user selects a value to be used in a stored procedure.

WebHMI is another aspect of Genesis64 that is very convenient for the developer and client alike. With a few clicks, a GraphWorX display can be hosted as a webpage on the internet, albeit only accessible through Internet Explorer. 

Learn more about DMC’s Iconics programming services.

*Screenshot from Iconics Genesis64 demo.

The post Review of the Iconics Genesis64 HMI/SCADA Development Software appeared first on DMC, Inc..

The Problem:
Refreshing datasources with a time trigger takes an increasingly long amount of time as more datasources are refreshed with the same trigger. This behavior becomes a significant hindrance when an HMI is used to display and edit data. This is because any changes made by the user to the data are only reflected in the displays when the corresponding datasource is refreshed. In other words, a very high refresh rate is required to ensure that the user sees the change made to the data relatively quickly, but a high refresh rate is not feasible when there are multiple datasources in Genesis64. In some instances, a single data refresh of all datasources took up to 30 seconds; this was unacceptable for our application and would be for most other interfaces too. 

The Workaround:
After a lot of experimentation, manual refreshing of datasources was the method that allowed for the fastest refreshing of data from the user’s perspective. A special datapoint that is provided in Genesis64 (Datasource.@@Refresh) can be written as well in order to manually refresh a particular datasource. This can be achieved by creating a process point or label, tying it to a datasource’s refresh point, and using a script to write to the process point when a button is clicked. 
In our application, any user action that could have potentially changed data in a datasource initiated a manual refresh of that datasource. While this increased development time, it ensured that the user saw the changes that were made within one second.

Learn more about DMC’s Iconics programming services.

*Screenshot from Iconics Genesis64 demo.

The post Refreshing Datasources in Iconics’ Genesis64 HMI/SCADA Development Software appeared first on DMC, Inc..

As an ICONICS System Integrator Partner, DMC will take part in the ICONICS 2013 Worldwide Customer Summit held from September 23 – 26, 2013 in Newport, Rhode Island. The theme for the event is  “Get Connected – Visualize, Analyze, Mobilize,” and programming will focus on the latest breakthroughs in real-time automation, analytics and mobile software technologies in a variety of industries. The summit aims to connect ICONICS users, integrators, and channel partners to share insight and best practices and showcase leading-edge software.

“This year’s conference connects the world of industrial automation, manufacturing and building automation with breakthrough technologies that are going to change the way we do business,” states Russ Agrusa, ICONICS President and CEO. “From advances in natural user interfaces to delivering 3D-rich dashboards on smart mobile devices, ICONICS connects you with the future of automation software.”

The post DMC Joins ICONICS System Integrator Partner Program appeared first on DMC, Inc..

Starting from the bottom, we can see that our operator-side HMI is exposed anywhere on the internal company network (with the correct login information) via Internet Explorer. This provides a reduction in downtime, because if HMI hardware fails, any other computer can be put in its place right away. Technology used for this implementation was ICONICS WebHMI, which easily converts between local HMI projects and HTML ActiveX Web pages.

Via the production network, the thin client speaks to one of two ICONICS DataWorx servers to send and receive production tags. ICONICS DataWorx has built-in redundancy and failover options which determine which of two OPC servers should be used to communicate to production devices such as PLCs.

Recipe data as well as data acquisition and reporting are stored in SQL Server 2008 R2. SQL has built-in features for customizable back-up and storage, which we are using to minimize the possibility of data loss. The SQL server communicates with our OPC server via a custom, configurable .NET service we have written, deployed and tested on several previous systems.

The last important step in reducing downtime is virtualization. Each of our three servers is virtualized using VMWare. This allows us to save backups of entire servers on independent storage devices, preserving all program installations and configurations in the event of a total meltdown of the physical servers.

Complete redundancy is not a simple task. A lot of thought has to go into specific requirements, hardware/software architecture, network layouts, and program configurations. Testing is also key (for us, simulation off-site of various failure modes provided insight into software configuration requirements). After working on this and previous redundant systems, I would recommend repeating the fundamentals described above:

1. Server-centric solutions with thin-client operation
2. Off-the-shelf solutions where available
3. Virtualization with independent back-ups of all servers

Happy programming!

Learn more about DMC's Iconics programming services.

The post Automation Redundancy Using ICONICS WebHMI Solutions appeared first on DMC, Inc..

DMC has often had to download a high number of values from a SQL server to an OPC server. In the past, this had usually been done with VBA code that was called from an Iconics HMI screen. The code looped through about 600 tags in less than a minute. The VBA code was always executing locally (on the same PC) as the OPC server it was writing to.

For a particular application, the HMI architecture switched to using WebHMI. Therefore, the VBA code needed to be converted to VBScript for compatibility with WebHMI. When a Graphworx WebHMI display is opened in a web browser on a thin client, the VBScript is executed on the thin client and not local to the OPC server, which is running on the WebHMI server.

As we implemented and tested our original VBScript, we experienced extremely slow execution time. The remote execution of the VBScript (whether in a client browser or on a remote Graphworx runtime) was taking more than 10 times as long as when we ran the same script locally on the server where the OPC server resided.

Original Approach

The original approach to writing to an OPC tag in the VBScript is captured in the subroutine below. Notice that one tag is accessed in the client.RequestDataPoint() function. When this subroutine is executed, it creates a subscription to an OPC tag that is not already subscribed to as an object on the display. It writes to the OPC tag and then releases the subscription as it exits the subroutine. According to Iconics, the releasing of the subscription has a time delay associated with it that is longer when the script is being executed on a remote client. Therefore, the extremely slow execution time experienced in the recipe download script was due to the extended delay of releasing the subscription of an OPC tag at the end of each single write.

' Write OPC tag. Return false if error is detected
Sub OPC_Write (Tag, Value)

  Set client = CreateObject("GenClientWrapper.Client") 
  
  ' Try to add tag
  On Error Resume Next
  Dim dp 
  Set dp = client.RequestDataPoint(Tag, 100, 0) 

  If dp Is Nothing Then
   MsgBox "Tag " & Tag & " not found!", vbCritical, "Sub: OPC_Write"
  Else
   dp.Value = Value
  End If
End Sub

' Write OPC tag. Return false if error is detected
Sub OPC_Write (Tag, Value)

  Set client = CreateObject("GenClientWrapper.Client") 
  
  ' Try to add tag
  On Error Resume Next
  Dim dp 
  Set dp = client.RequestDataPoint(Tag, 100, 0) 

  If dp Is Nothing Then
   MsgBox "Tag " & Tag & " not found!", vbCritical, "Sub: OPC_Write"
  Else
   dp.Value = Value
  End If
End Sub

Resolution Approach

The new approach to writing to an OPC tag in the VBScript is captured in the subroutine below called “OPC_Write2.” The key difference with this approach is that tag subscriptions are aggregated into a global array and held throughout the whole download sequence. Tag subscriptions are not released until the whole download script has completed, and thus no noticeable subscription release delay is experienced between individual tag writes or even at the end of the download sequence.

Data is passed to the subroutine in the same manner as the older subroutine, but some additional arguments are passed in with the tag and value. “myDataPoints” is a global array of 600 and myIndex is a global variable that is incremented every time “OPC_Write2” is called. The size of “myDataPoints” is set so that it is larger than the total number of tags to be written. Each piece of data to be written to an OPC tag is added to the array with Set myDataPoints(myIndex) = myClient.RequestDataPoint(Tag, 100, 0). “myIndex” is then incremented every time OPC_Write2 is called so that the next time OPC_Write2 is called myClient.RequestDataPoint() is assigned to the next index in the array. Because myClient.RequestDataPoint() is being assigned to a global array we maintain the scope of the function. This means that the subscription is maintained and the delay that was experienced when unsubscribing to a tag and checking for pending writes will no longer occur.

Sub OPC_Write2 (Tag, Value, ByRef myClient, ByRef myDataPoints, ByRef myIndex)
	
	' Try to add tag
	On Error Resume Next
	Set myDataPoints(myIndex) = myClient.RequestDataPoint(Tag, 100, 0) 

	If myDataPoints(myIndex) Is Nothing Then
		MsgBox "Tag " & Tag & " not found!", vbCritical, "Sub: OPC_Write"
	Else
			 myDataPoints(myIndex).Value = Value
	End If

	myIndex = myIndex + 1

End Sub

Sub OPC_Write2 (Tag, Value, ByRef myClient, ByRef myDataPoints, ByRef myIndex)
	
	' Try to add tag
	On Error Resume Next
	Set myDataPoints(myIndex) = myClient.RequestDataPoint(Tag, 100, 0) 

	If myDataPoints(myIndex) Is Nothing Then
		MsgBox "Tag " & Tag & " not found!", vbCritical, "Sub: OPC_Write"
	Else
			 myDataPoints(myIndex).Value = Value
	End If

	myIndex = myIndex + 1

End Sub

Learn more about DMC’s Iconics programming services.

The post Iconics, VBA, VBScript, and Writing to OPC Tags appeared first on DMC, Inc..

I started with the simplest solution using a “GetCommandLineA” Windows API function from kernel32.dll. It was supposed to return a pointer to the command line string, so I assumed that its return type would be string (sounds logical to me).

' The return type of the GetCommandLineA is long
' But it is supposed to be a pointer to the string. 
' Assumming that all VBA strings are passed by pointers
' Just declare it's return type to be a string
Declare Function GetCommandLineA Lib "Kernel32" () As String
 
Sub ReadCmdLine()

   Dim strCmdLine As String ' Command line string   
   ' Read command line parameters into the string
   strCmdLine = GetCommandLineA

End Sub

' The return type of the GetCommandLineA is long
' But it is supposed to be a pointer to the string. 
' Assumming that all VBA strings are passed by pointers
' Just declare it's return type to be a string
Declare Function GetCommandLineA Lib "Kernel32" () As String
 
Sub ReadCmdLine()

   Dim strCmdLine As String ' Command line string   
   ' Read command line parameters into the string
   strCmdLine = GetCommandLineA

End Sub

Surprise – it caused exception and crashed the application. Hm, apparently VBA handles a pointer to the string differently than GetCommandLineA. Not wanting to spend time figuring out why, I decided to copy the string to VBA string using another kernel32.dll function “lstrcpynA”.

' Declare the return type to be a pointer (long)
Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _ 
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string     

   pCmdLine = GetCommandLineA
   ' Copy from the pointer to VBA-Style string 
   ' 300 characters for command line seems to be enough
   lstrcpynA strCmdLine , pCmdLine, 300	   

End Sub

' Declare the return type to be a pointer (long)
Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _ 
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string     

   pCmdLine = GetCommandLineA
   ' Copy from the pointer to VBA-Style string 
   ' 300 characters for command line seems to be enough
   lstrcpynA strCmdLine , pCmdLine, 300	   

End Sub

This worked better by no longer crashing the application, but the strCmdLine was always empty. After short Google search I found this Microsoft article. Apparently lstrcpynA function (as other DLL functions returning strings) can’t change the size of the VBA-style string. In order to reserve the space for that return data, we need to fill the string with a bunch of zeros (vbNullChar).

Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string   

   ' Get the pointer to the command line string
   pCmdLine = GetCommandLineA

   ' Fill the string with zeros
   ' 300 characters for command line seems to be enough
   strCmdLine = String[DollarSign](300, vbNullChar)

   ' Copy from the pointer to VBA-style string
   lstrcpynA strCmdLine , pCmdLine, Len(strCmdLine )

   ' At this point we got the string
   ' But rest of it filled with 0 characters.
   strCmdLine = Left(strCmdLine , InStr(1, strCmdLine , _
      vbNullChar) - 1)
   	   
End Sub

Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string   

   ' Get the pointer to the command line string
   pCmdLine = GetCommandLineA

   ' Fill the string with zeros
   ' 300 characters for command line seems to be enough
   strCmdLine = String[DollarSign](300, vbNullChar)

   ' Copy from the pointer to VBA-style string
   lstrcpynA strCmdLine , pCmdLine, Len(strCmdLine )

   ' At this point we got the string
   ' But rest of it filled with 0 characters.
   strCmdLine = Left(strCmdLine , InStr(1, strCmdLine , _
      vbNullChar) - 1)
   	   
End Sub

This code finally worked as expected, returning command line arguments.

Hopefully, this article is useful in saving someone 15 minutes of frustration.

Learn more about DMC’s software and web development services.

The post Read Command Line Parameters from VBA appeared first on DMC, Inc..

Good, now you know what I am talking about.

We’ll talk about GraphWorX32, this is HMI graphical display application. One of the control available in GraphWorX32 is drop-down list (Statefield). This is pretty cool drop-down menu, but values on the list have to be hardcoded during screen design and can’t be updated at runtime.

At the same time GraphWorX32 supports VBA scripting language. So it’s totally possible to update drop-down list from VBA code. This is how I do it:

' In order to update drop-down values we have to delete stateField object and re-create it again
Dim strStateConfiguration As String
Dim objFieldToUpdate As Object
Dim L, T, W, H
Dim Fnt As IFontDisp
Dim objFieldToUpdateText As GwxText
Dim objNewText As GwxText
Dim objNewStateField As Object
  
' StateField object attaches to existing text object, so we have to find text object first, assuming it has "StateField_txt" name
Set objFieldToUpdate = ThisDisplay.GetVisibleObjectFromName("StateField_txt")
' Get text objects position/size, we have to create new object with the same size
objFieldToUpdate.GetObjectDimensions2 L, T, W, H

' Cast text object to the GwxText type
Set objFieldToUpdateText = objFieldToUpdate
' Get text object font
Set Fnt = objFieldToUpdateText.Font
            
' Delete text object
ThisDisplay.DeleteObject ("StateField_txt")
        
' Create new text object, set the same position/size and font as original text object.
' We didn't store original text align, colors etc, so we just hardcode it
Set objNewText = ThisDisplay.CreateText(0, 0, "", TextAlignLeft, False, False, RGB(128, 128, 128), RGB(0, 0, 0), 0, LineNone, False, RGB(0, 0, 0), EdgeNone, False, "StateField_txt")
Set objNewText .Font = Fnt
objNewText.SetObjectDimensions L, T, W, H

' Here we have to create new drop-down list. Just assign couple values
strStateConfiguration = ""
strStateConfiguration = strStateConfiguration + "value1" & Chr(9) & "Drop-Down-Text1" & Chr(13) & Chr(10)
strStateConfiguration = strStateConfiguration + "value2" & Chr(9) & "Drop-Down-Text2" & Chr(13) & Chr(10)

' Creating StateField and attach it to text object. OPC tag string is hardcoded in this example
Set objNewStateField = ThisDisplay.CreateStateField("StateField_txt", "StateField_stat", True, True, False, 0, strStateConfiguration, "")
objNewStateField.dataSource = "<Path_to_my_OPC_Tag>"

' In order to update drop-down values we have to delete stateField object and re-create it again
Dim strStateConfiguration As String
Dim objFieldToUpdate As Object
Dim L, T, W, H
Dim Fnt As IFontDisp
Dim objFieldToUpdateText As GwxText
Dim objNewText As GwxText
Dim objNewStateField As Object
  
' StateField object attaches to existing text object, so we have to find text object first, assuming it has "StateField_txt" name
Set objFieldToUpdate = ThisDisplay.GetVisibleObjectFromName("StateField_txt")
' Get text objects position/size, we have to create new object with the same size
objFieldToUpdate.GetObjectDimensions2 L, T, W, H

' Cast text object to the GwxText type
Set objFieldToUpdateText = objFieldToUpdate
' Get text object font
Set Fnt = objFieldToUpdateText.Font
            
' Delete text object
ThisDisplay.DeleteObject ("StateField_txt")
        
' Create new text object, set the same position/size and font as original text object.
' We didn't store original text align, colors etc, so we just hardcode it
Set objNewText = ThisDisplay.CreateText(0, 0, "", TextAlignLeft, False, False, RGB(128, 128, 128), RGB(0, 0, 0), 0, LineNone, False, RGB(0, 0, 0), EdgeNone, False, "StateField_txt")
Set objNewText .Font = Fnt
objNewText.SetObjectDimensions L, T, W, H

' Here we have to create new drop-down list. Just assign couple values
strStateConfiguration = ""
strStateConfiguration = strStateConfiguration + "value1" & Chr(9) & "Drop-Down-Text1" & Chr(13) & Chr(10)
strStateConfiguration = strStateConfiguration + "value2" & Chr(9) & "Drop-Down-Text2" & Chr(13) & Chr(10)

' Creating StateField and attach it to text object. OPC tag string is hardcoded in this example
Set objNewStateField = ThisDisplay.CreateStateField("StateField_txt", "StateField_stat", True, True, False, 0, strStateConfiguration, "")
objNewStateField.dataSource = "<Path_to_my_OPC_Tag>"

There are a couple things to keep in mind:

• This code needs to be run in PreRuntimeStart event
• You can’t run this code during runtime, only at design mode
• PreRuntimeStart event called only during transition from design mode to runtime mode
• If screen opens from another screen which already in runtime mode – PreRuntimeStart event won’t be called
• Depending on the application it could be several scenarios how to force drop-down list update. For example: you could open screen in design mode and in DisplayLoad event switch it to runtime mode

Happy coding!

The post Populating Iconics/GraphWorX32 Drop-down list (Statefield) from VBA appeared first on DMC, Inc..