This version of Internet Explorer is either no longer supported by Microsoft, or is obsolete and some features of our store may no longer be supported.
Please consider upgrading or use a different browser.
Cookies are not enabled on your browser.
Cookies are required for our site. Please enable cookies in your browser preferences to continue.
Our offices will be closed Friday, July 3rd, to celebrate Independence Day
For Thursday order cutoff times, see our shipping policies. Orders placed after the Thursday cutoff, will process on Monday, July 6th.
(VID-POV-0018) - Learn how to create your own tables or "Driver Sheets" for those times when Tag Integration doesn't give you quite enough control over the tag. This is especially helpful when you want to automatically scale a tag or work with arrays of tags.
**Prices were valid at the time the video was released and are subject to change.
Software Version used in this video: Point of View v7.1 Service Pack 3 Patch 5
In the previous videos we found connecting Point of View to a Do-more is easy. You just export the Do-more tags to a CSV file, and then tell Point of View where to find that file. Point of view calls this Tag Integration. We also saw that Tag integration has some limitations. Like if you use one item of a structured heap item the entire size of the heap item gets deducted from your tag license count. The way around that is to use something called a Driver Sheet. There is a Main Driver Sheet and Standard Driver Sheet. The difference is the Do-more Main driver sheet can be filled in with tag information from any Do-more in the system and any combination of data types for those Do-mores. The Standard driver sheet can only talk to one Do-more and any data type on that Do-more. But, you can have up to 999 standard driver sheets so you can create one for every Do-more you need to communicate with. Since the Main Driver sheet can talk to any combination of devices and data types, you only ever need one of those. The reason for having two different types of driver sheets is triggering. The Main Driver sheet is updated at a periodic rate which defaults to every 600ms. The Standard Driver sheet has more options for triggering when the tags get updated – you can update on an alarm or an event. Or you can schedule updates to do something like a burst of communications at 2am every morning, stuff like that. With standard driver sheets you can get very specific with the triggering because you are only talking to one Do-more. In this video, we’ll focus primarily on the Main Driver sheet. It will be all you need most of the time. And once you understand how to setup the Main Driver sheet, you’ll be able to do the Standard driver sheet too. Using a Main Driver sheet is easy. You just tell it which element in the CSV file that you want to access as a standalone element and you’re done. Let’s do a couple examples. You’ll see pretty quick how this comes together and how easy it is. To create a main driver sheet, just go to the communications tab, right click on drivers, Add drivers. Select the Domore driver and hit ok. Double click on that driver sheet to edit it. You can put a tag here to disable the driver sheet – maybe you only want to access this particular controller type during certain hours of the day, for example. These are status tags. We’re going to be reading some tags so I want to keep an eye on any errors we might get during a read so I’ll add a tag here. This Min Max check box will change these columns to Min and Max which Point of View will use to do scaling in the tags properties dialog. We’ll cover that later in a video on scaling tags. Down here we enter the tags we want point of view to retrieve from the Do-more. To do that, we’ll need some Do-more tags, so let’s create some in Do-more designer. PLC, Memory configuration. Lets add a block of bits. Add Memory block. We’ll call it New BIT Block, it contains bits, and let’s leave it at 256 bits for this demo. Great. And let’s create another one with strings. We’ll call it New String Block, it’s a block of strings, let’s make the strings 64 characters each and lets make 27 of those strings in the block. Great, we have two new memory blocks for Point of View to access. Let’s add a couple Heap items. First let’s add a PID structure. We’ll call it New PID Item. It’s a PID structure. Now let’s create a Program Structure, but instead of doing it here, let’s actually create a program. Right click on programs and let’s call it New Program. Now if we look in the memory dialog, we see a new heap item called New Program. Perfect. Let save those changes and write them out to the Do-more. And let’s export the CSV file so we have all of these new tags. We’ll call that Do-more Tags and we need to make sure we use the C-more version of the file and store it IN the project folder so it is easy to find. So all we did here was create two new index-able memory blocks and two new structured heap items and export the tags to a file. Let’s go back to Point of View and setup the driver sheet to access those guys. In this column we enter the name we want Point of View to use. We’ll access the PID Set Point, so let’s call this PID Set Point. Yes we want to create a new tag and it needs to be a real. You can see the tag count increment by one. The station is NORMALLY the IP address of the Do-more. BUT for any user defined memory blocks, like the ones we just created, you also have to specify the CSV file too. Tell Point of View to look in the current folder, for the CSV file we just exported from Do-more Designer, colon, IP address. You can also add a colon port number and colon password if you want to. We’ll take the default port number and don’t need a password so this is fine. In this column we tell Point of view exactly what we need to access. If we look in the csv file, we see there are templates for every memory type. Timers, counter, strings, PID loops, etc. We are going to want the set point of a PID loop so that looks like its going to be a dot SP. If we scroll down to the bottom we see the User Heap Items and our PID structure. I’ll copy that name so I don’t mistype it, Paste it in my driver sheet and append the SP item that we want. And we’ll leave this at read write so we can do both from Point of view. Well, now that we have defined this tag, let’s use it. I’ll grab a text box, drop it on the screen. Double click and browse to the new tag we just created which is going to be in the Project folder. And it was a real and there it is. Double click to select it. Let’s add a title to this box called PID Setpoint. And while we are here, let’s add the Driver Sheet Read status to a text box. Great. Save all and run it. Uh oh .. what happened? Why aren’t we getting the result here? Well, if we look this error code up in the help file, which is under help, communications drivers, DOMORE driver, scroll to the bottom; we see error 34 is an invalid address error. Back in the driver sheet that means something is wrong here or here. I got the dot backslash, and the .csv. I tried pinging the IP address and that was good. The name of the block was copied directly from the driver sheet and I know set point is SP. This all looks fine. So what’s going on? Well, it turns out that if you have the CSV file open when you start the app, Point of View can access it. So I’m going to close the csv file – don’t save any changes - and restart the app. And sure enough, everything is working. If I change the setpoint in Domore, we see the result in Point of View. And if we change it in Point of View we see the result appear down on the Do-more. Perfect. So remember that bit about the CSV file being open that catches me all the time. By the way, You CAN open the CSV file AFTER you start the app, it just has to be closed while the app is starting so the app can read all the current Do-more memory configuration info. Here I’ve add the other memory types we created. We’re extracting bit three from the block of 256 bits we created, String number 7 and the program done bit from the program module we created. Note that the indexes are appended; there aren’t any parenthesis or brackets. On our screen I’ve already created the text boxes. Each of these just uses the project tag we just created. Save everything, run the app. If I change string 7 on the Do-more we see that appear in Point of view. If I change Bit 3 we see that in point of view. And of course, the program done bit is zero because we never actually used that program module on the do-more. The key thing to notice here is our tag count. It’s just the 5 tags we created. Just for fun, let’s bring some of these in via tag integration and see what happens. Project tab, communication, add. We want the Do-more driver, and well call it Do-more Integrated Tags. Enter the IP Address, and browse to the csv file we put in in the project folder. A wesome. Now we can see the integrated tags Home tab, object finder. There’s the folder we just created and here are all the integrated tags that are available. Let’s create a text box for the PID set point again, but this time use the integrated tag, not the main driver sheet. Same as before, except now we look under devices, the new folder we created, heap items and there it is. Click on that, then click on this to select which member we want to use. We want the Setpoint. You can see the full description of the tag here. Before we click on OK notice the tag count is 5. Hit OK and look what happened. The tag count went up by 19! Remember, with tag integration if you use only one element of a structured heap item, you get penalized for ALL the tags in the structure. OK, save everything. Run it. If we change the set point on the Do-more we now see it in both the driver sheet tag and the integrated tag. The only difference is the drive sheet version of the set point tag only took one tag from the license count. The integrated set point tag cost us 19 tags, because that was the size of the PID structure. Here’s a question, how many tags would we loose if we used tag integration to look at the program bit? Let’s try it. Copy the driver sheet version of the done bit text box and paste it over here. Double click on that to change the tag to the integrated version. Before we hit OK note that the current tag count is 24. Hit OK and look what happens. Using that single done bit in the Program Structure via Tag Integration cost us 147 tags from our license because the program structure has 147 elements in it! So if you need to access a structured memory element on the Do-more from Point of view, definitely consider using the Main Driver sheet. It can save you a lot of tags on your license. What about indexed memory blocks, do they have the same issue? Let’s find out. Earlier on the Main Driver sheet we created a Bit3 Tag to pull bit 3 out of an array of 256 bits and we created a string7 tag to pull string 7 out of a block of twenty seven 64 character strings. Each one of those only used one tag from our license. And here are the text boxes we used earlier to display those driver sheet tags. Now what if we do that via tag integration? Will we take a license hit for ALL 256 bits or ALL 27 string tags in the blocks we created? Let’s find out. Here’s a text box for the Tag integration version of Bit 3. We browse to the Devices folder – not the project folder - in the Do-more Integrated Tags folder we created, in Memory blocks and there’s the New Bit Block we created. We’ll grab bit number 3. The tag count is currently 171, and when we hit OK and the tag count increases by just ONE- not the entire size of the array or block of bits, which in this example is 256. Cool. Here’s a text box for the Tag Integration version of String 7. We browse to the Devices folder, in the Do-more Integrated Tags folder we created, in Memory blocks and there’s the New String Block We created. We’ll grab string number 7.The Tag count is 172, double click an dit also only increased by 1 tag! So accessing blocks of indexed memory or ‘arrays’ on the Do-more via tag integration doesn’t cost us any additional tags. That’s good to know. So the bottom line is you can access all of the Do-more’s memory via tag integration, but if you want to access a structured memory element your tag count will go up by the size of the entire structure. So, if you need to minimize tag count when using structured elements, or want to scale tags automatically as they come into Point of View, then you’ll need to use a Driver sheet to specify exactly what you want to bring in. Well, by now you should have a pretty good idea of how to use a Main Driver Sheet to access memory on the Do-more. To create a standard driver sheet, just go to the communications tab, right click on the Do more folder, and insert a standard driver sheet. The only difference is you have more triggering options and this driver sheet can only talk to ONE Do-more so the IP address of that Do-more – and CSV file if needed - goes up here. This field is not used on the Do-more driver and the rest is just like the Main Driver sheet. What you want to call the tag in Point of View goes here and the exact memory element you want to access goes here. There isn’t a column to control reading and writing because you control that with these tags up here. If you leave these fields empty, then that means the tag is readable and writeable at all times. If you need any help, please contact AutomationDirect’s free award winning tech support during regular business hours. They will be happy to help. And don’t forget the forums – there are lots of folks there that love to share their years of experience. Just don’t post any questions directed at AutomationDirect’s support team there, they don’t monitor the forums on a regular basis.