WinPLC and DoMore

[DLTimmons]

What would be the best way to exchange data between a Do-More and a WinPLC. I have a system of WinPLC's and a server I need to add a Do-More to get better control of one part of the system.

[BobO]

Think-n-Do WinPLCs? Gosh...I have no idea. I don't know what they speak. The Do-more side can be made to do dang near anything with the custom protocol instructions and sufficient skill...but I know very little about TnD.

[DLTimmons]

Currently the server direct writes and reads to the WinPLC memory. Can't do that with the Do-More plus our IT group does not have the resources at this time to do a rewrite of the server. What about running the Winplc serial port in Modbus slave and the Do-More Modbus master RTU serial and function like a touch panel?

I would be moving all control to the Do-More. I have to have some Ctrio2s for what I needing to do. 

[BobO]

I have next to zero experience with TnD. If they support Modbus slave on the serial port, then yes, that's what I would use.

[MikeS]

I posed this question to the ThinknDo support group and got this response:

The WinPLC can behave as a Modbus RTU Server or a Modbus/TCP Server. In both cases the WinPLC behaves just as if an HMI panel were asking for info or writing. In both cases, either the Serial Port or the Ethernet port must be set up as such in IOView. This all works seamlessly and pretty much automatic. The Modbus Register Mapping is available at http://phoenixcontact.custhelp.com/app/answers/detail/a_id/1086


The WinPLC can also behave as a Modbus RTU Client, although with MUCH more effort. One must use the CALL Block and then from within the CALL block selections, choose the Modbus Master charts, and specify the register(s) desired. The user can only request one register (or contiguous set of registers) at a time and the approach is quite synchronous and must be managed for each register request of the Server. See http://phoenixcontact.custhelp.com/app/answers/detail/a_id/807

Are you saying the existing server is NOT currently using Modbus protocol to read/write the WinPLC memory ? or are they reading/writing using a custom protocol ?

[DLTimmons]

I posed this question to the ThinknDo support group and got this response:

The WinPLC can behave as a Modbus RTU Server or a Modbus/TCP Server. In both cases the WinPLC behaves just as if an HMI panel were asking for info or writing. In both cases, either the Serial Port or the Ethernet port must be set up as such in IOView. This all works seamlessly and pretty much automatic. The Modbus Register Mapping is available at http://phoenixcontact.custhelp.com/app/answers/detail/a_id/1086


The WinPLC can also behave as a Modbus RTU Client, although with MUCH more effort. One must use the CALL Block and then from within the CALL block selections, choose the Modbus Master charts, and specify the register(s) desired. The user can only request one register (or contiguous set of registers) at a time and the approach is quite synchronous and must be managed for each register request of the Server. See http://phoenixcontact.custhelp.com/app/answers/detail/a_id/807

Are you saying the existing server is NOT currently using Modbus protocol to read/write the WinPLC memory ? or are they reading/writing using a custom protocol ?

Thanks that link will help me get started.

I'm not sure how it reading the memory at this time the guy that set that up is no long with the company and was very secretive about how he did things it function much like apptracker does. It read the map file saved on the server and read and writes all memory even strings based on the tag name. The problem is there are 11 WinPLCs the serve communicates with and there is peer to peer communication going on at the same time so changing out just one with a Do-More is not an option. So what I am looking at is using a WinPLC as a interface to the Do-More so the server will see a Winplc that passes all data to the Do-More that will now controlling the Crane.

So base on the Modbus not addressing string is not Modbus being used. We write commands as string to the WinPLCs then parse them out in the PLC.

The D-More is going to fix a lot of problem we have been fighting for years.

[DLTimmons]

In both cases, either the Serial Port or the Ethernet port must be set up as such in IOView. This all works seamlessly and pretty much automatic.

I can not get a response from the winplc. I can see the receive LED on the serio light up so the transmission is getting to the WinPLC. How do I setup IOVeiw?

Update

data bit set wrong it does not like 7 data bits

[Controls Guy]

The guy used a WinPLC to control a CRANE??  I hope the safeties are all hardwired (course I'd hope that regardless of the controller).

That would explain the job-security programming mode; he was trying to keep from getting shot! 

[BobO]

The guy used a WinPLC to control a CRANE??  I hope the safeties are all hardwired (course I'd hope that regardless of the controller).

That would explain the job-security programming mode; he was trying to keep from getting shot! 

You dis'in my hardware?!?

[Controls Guy]

I'm dissin Think-N-Do for critical applications.  Heck, I'm dissin the use of TnD for almost anything.   

Should have said TnD instead of "WinPLC".  I realize the two are not one-and-the-same.

[DLTimmons]

The guy used a WinPLC to control a CRANE??  I hope the safeties are all hardwired (course I'd hope that regardless of the controller).

That would explain the job-security programming mode; he was trying to keep from getting shot! 

You dis'in my hardware?!?

Yep 4 cranes controlled with WinPLCs    10 years ago WinPLCs were pretty powerful use quite a few of them.

That I hope to soon be Do-More with servo drives

Still not quite getting the Modbus talking correctly the Winplc is responding but the Do-More acting like it not seeing the response at lest I do not see the c bits change I am reading into.

[Controls Guy]

What little work I did with TnD, it never really struck me as a toolbox with which to build a robust control solution.  Not that I'm so confident in PLC's I'd use a generic one as a safety controller.  Functional controller, with all necessary safety devices, crash and obstruction sensors, brakes, etc., hardwired, fine.

The format of TnD code seems like it's hard to review and verify.  It just has this band-aid and baling wire feel about it to me, and I cringe at the idea of doing anything critical with it.

Anyway, why not divide and conquer?   Use some PC-based HMI software or a Modbus utility to poll the WinPLC and see if it will talk.  Or if you have a hardware HMI lying around, use that.

[DLTimmons]

I got a Do-More and Winplc talking right now just a few C bits to Flags in the WinPLC. Will have to figure out the Strings and how I am going to handle them.

[BobO]

I'm dissin Think-N-Do for critical applications.  Heck, I'm dissin the use of TnD for almost anything.   

Should have said TnD instead of "WinPLC".  I realize the two are not one-and-the-same.

OK...good enough. I'll let this one slide.

The hardware really isn't bad. The processor, oddly enough, is faster than the DM1...but...the SH3 processor and compilers are not particularly efficient. The SH3 is about 0.4 mips/Mhz...whereas the DM1 is more like 1.1 mips/Mhz. Of course the real power of the DM1 is the custom logic co-processor...it absolutely smokes. For comparison we put the Do-more engine on a 1Ghz Beagle Bone without the logic co-pro...and it was about half as fast as the DM1 for accelerated instructions, even though the clock speed is over 13x faster. Hardware acceleration is your friend.

[BobO]

I got a Do-More and Winplc talking right now just a few C bits to Flags in the WinPLC. Will have to figure out the Strings and how I am going to handle them.

From the Do-more side, use STRGETB to extract data from a string structure and STRPUTB to put them back in. In a future version we want to enhance the Modbus instructions to go into and out of strings, but for now you have to do it manually.