DO-MORE AND KEPDIRECT

[ddubs2248]

I have been toying with the Do-More Sim and KepDirect today and wanted to share some comments/feedback (also perhaps there is another OPC Server that is better suited, perhaps ones with the new Do-More drivers).  Let me first state that I have all of one week under my KEPDirect belt and one day of Do-More SIM.

Programs Used: 
Do-More PLC Software: Example PID program included with the downloaded Software (Controls oven temperature)
OPC Server:  KepDirect V5.5
HMI:  Lookout Direct running on XP Virtual Machine
Windows PC:  Running Windows 7 64 Bit
Data Acquisition:  DasyLab v10.0

1st issue I encountered was connecting the OPC Server.  KEPDirect is limited to the DirectLogic structured block names and data types (X0, Y0, C0, V-Memory, etc).  BobO suggested that I use the DLV, DLX, DLY block names in the ladder program.  So a simple MOVE command (awesome by the way) moving SimPID.PV to DLV2002 made the OPC server recgonize the V2002 data.
 :)Positives
I could move the data to the OPC server and have DasyLab grab the data, plot, and write to file from the OPC server.
I could also display the data directly to LookoutDirect HMI as a simple expression
 :-\Negatives
I could only move the data as an unsigned word, which gave me an integer value (XXX) and did not have the precision of SimPID.PV (XXX.XX)

I got around this by performing Math on the SimPID.PV (multiplied by 10), performed the MOVE to DLV2002, and then scaled the value (divided by 10) in DasyLab to gain precision (XXX.X).  If new drivers could communicate directly to SimPID.PV that would be more efficient.

2nd issue was connecting I/O (X0, Y0, WX0, etc).  I first wanted to read if the PID loop was in manual or auto mode (which is controlled by X0 low or high respectively).  A simple MOVE command sending X0 to DLX0, made the register appear on the OPC Server, HMI, and Data Acquisition.
However, real world outputs (Y's) did not work out as well. 

With a standard DL06, operating Y's can be done through the OPC Server by writing a 0 or a 1 and the physical PLC will function the respective output relays (Y1, 2, 3, etc).
With the DO-More PLC, I was hoping that it was going to be a simple MOVE DLY15 (since Y15 is not in the example program) to Y15 to control the real world output.  What I found was DLY15 (or Y15 on the OPC Server) actually functioned Y10 of the Do-More PLC.  The way around this was to assign a V-Memory location (I chose V2020 on the OPC) performed a MOVE to Y15 and was able to function the output by passing a 0 or 1 to operate Y15.
 :)Positives
It can be done!
 :(Negatives
Hopefully there is a better way!

Perhaps there is a different approach that I need to take or perhaps this is something (drivers) that Host is working on.  I tried the import function (.csv) in the KEPDirect OPC Server, but it did not allow me to upload my "Tags" or Nicknames.  Again perhaps there is an easy fix that I am missing. 

I am going to continue to play on this end, but I thought I would provide my initial findings and hopefully get some help or provide some help as this topic expands.

Thank you Host thus far, and keep up the great work!

[BobO]

Here's the issue: The DirectLogic protocol that you are using with KEPDirect is supported as a 'guest' protocol...which means...it only has access to a limited area of memory. That is by design, and for a very important reason: Neither the original DirectLogic protocol or Modbus are secure. After having interface with the Department of Homeland Security on the issue of system vulnerability, we have started moving toward better security in our PLC.

There are other issues that are more mundane, perhaps, but just as significant. The memory map of a Do-more controller is completely configurable, by creating new blocks, heap items, accessing structures, changing block lengths, etc. There is simply no practical way for the DirectLogic protocol to map into Do-more's memory. Even the simple case of V memory you were describing is broken worse than you realize. All of Do-more's native memory blocks have a decimal radix...while all of DirectLogic's are octal. When you were trying to reference V2000 (octal) from KEPDirect, if it were mapped to Do-more's V, you would have been accessing Do-more's V1024 (decimal) instead...and Do-more's V2000 (decimal) would have required V3720 (octal) from KEPDirect. Not the most intuitive. Rather than make a futile effort to map DirectLogic to Do-more, while simultaneously exposing Do-more's internal memory to network attack, we instead chose to create small areas of DLn 'guest' memories that are octal for simplicity, and more importantly, isolated from internal memory. The same thing applies to Modbus, and there are Mnn guest memories for Modbus servers.

So...the ability to use an OPC server to turn on a physical I/O point via an unsecured protocol is not something that I would brag about or want in my controller. I know that sounds a little harsh...but that is the reality of networked automation in the modern era.

As for accessing a floating point value through DLV, it isn't hard, it just takes two locations the same way floats require two Vs in DL. In Do-more do a "MOVE SimPID.PV DLV2000:R". Rather than converting the floating point value to an unsigned word, it will write a float to DLV2000 and DLV2001 using 'casting'. Check out help system topic DMD0309 for more details on casting. Not sure what it takes from KEPDirect to allow access to reals, but since DL PLCs support them, I suspect there is some way to tell KEPDirect you want to read two Vs as a real.

Hope this helps.

[odwyerpw]

Bob,
Thanks for taking the time to respond to the original poster so carefully.  I was having similar issues against my actual H2-DM1E, but eventually started to get it after I educated myself a little on how the DL260 and Kepware worked together by reading through the manuals freely available on the AD site! 

The information about the Double V location to house a real will be very helpful. I'll get back at this OPC/DoMore stuff on Thursday and report my sucess....after I read your contribution two or three more times.

Orginal Poster,
Thank you for sharing your experience. Very good information.

Peter

[ddubs2248]

Okay back at again!  I am trying to utilize the TOP Server (version 5, OPC server from Software Toolbox) with the Automation Direct ECOM driver and Modbus TCP/IP Driver.  I am still working with the PID Control Example in the Do-More Designer.  I have been trying to do the following with the publish cod block but have not had success:

1.  WY0 (PropGasReg) to MHR1 (which I thought was 40001, Modbus holding register)
2.  WY0 (PropGasReg) to V3000 (I created a new device for this one that followed the AD ECOM driver on the TOP Server)

I was able to verify that V3000 was corresponding to WY0 in the Data View of the Do-More Designer.  But in both of the above cases I was not able to see the value change/update in the OPC Quick Client it just shows to be zero.

I am trying to communicate values/coils out of the DoMore SIM PLC so that I can experiment with Cogent HMI and Inductive Automation's Ignition.  Any input, advice, or anyone that has been successful communicating from a DoMore PLC to Cogent or Ignition, please chime in!!

Thanks for the assistance!!  Greatly appreciated!

[ddubs2248]

It seems I was successful with Do-More to Cogent.  It seems I was having issues with IP addressing.  I am running Do-More SIM, TOP Server, and Cogent on same laptop.  I had to use the MRX/MWX to pass the values.  I am going to continue working (now with Ignition) and then I should be able to start writing some programs!  I will update as needed.

[BobO]

We're here to help! Just ask.

[ddubs2248]

Now successful with transferring two modbus values into Inductive Automation's Ignition and Cogent DataHub.  If I was going to write and read multiple modbus values then should I do the following in the Do-More Program?

1.  Modbus Writes on $BottomOfScan
2.  Modbus Reads on $TopOfScan
3.  Create Heap item(s) to allow writes/reads to happen in minimum amout of code blocks (ie create heap items for MyPressureGauges, MyValveControls, etc?)

Just trying to determine the best way to have data through-put as at times I may need to capture 50 S/s on 5-10 analog pressure gauges.

Thanks for Host's help BobO!

[BobO]

Modbus instructions are multi-scan, so putting them in $TopofScan or $BottomofScan is useful for code organization, but doesn't have a major impact on results. If you were interacting with synchronous physical IO, there may be a bigger significance.

As for optimizing performance, it's pretty straightforward. Each device can transact only one comm at a time, so if your server can handle multiple connections, creating more devices allows more than one transaction to be active at a time. At the , you want one device per server. Using a single device with more than one server is death to performance.

Then minimize the number of transactions per server by grouping data and accessing the max number of items per transaction. Since MRX and MWX can access all internal memory there is no need to create new memory blocks or heap items unless that is useful to you fur program organization.

[jbenek]

Has anyone sucessfully acessed a floating point value from DO-MORE into KEPDirect?

Ive been trying now for a bit and cannot get it to work. I can get the whole number but no decimal points.


Im reading Data from a MODBUS device and dumping it into DO-MORE V memory. Then doing conversions to it to give me a decimal value. I tried taking the raw value and making my DLV data point the output from the math instruction but it still is dropping off the decimals.

Am I doing something wrong? Or is it just not possible?

[franji1]

I get it now

[Modbus Slave] slave to Do-more

[Do-more PLC] slave to Kep

[Kep Server]

My bad.

Since Kep Server accesses DLV, just change the result of the MATH from a simple DLV to a REAL CAST of (e.g. DLV22:R).  This tells Do-more to treat the DLV location as 32 bit REAL register, not the default unsigned 16 bit that DLV is.  For :R REAL casting to work on DLV, the address must be EVEN (so you can't do DLV19:R).  You may have to adjust your memory a little.

But then in your Kep software, you must configure the tag to look at the "V" location as a REAL.

[jbenek]

Dismiss my question, I figured it out. I didnt really understand casting..... I talked to Frank at ADC and he got me all straight. Works like a charm now!

[franji1]

Dismiss my question, I figured it out. I didnt really understand casting..... I talked to Frank at ADC and he got me all straight. Works like a charm now!

Great!