Need to write a MC protocol driver

[Peter Nachtwey 15]

I need to write a MC protocol driver for the Q series so our product will respond to read and write requests from the Q series PLC. I need to write a driver for both serial and Ethernet. Has anybody on this forum done this? If so, what were the 'gotchas'? How much time did it take? Is there any problem in limiting my communications to just the binary data? Most numbers will be in floating point format so two words will need to be transfered for each floating point number. I am just rounding up the equipment now and will start this or next week. The protocol looks easy enough if I am reading the documentation right.

[Peter Nachtwey 15]

It looks like I am breaking new ground again. OK. fine. I have other questions that someone may have the answer to. What blocks or functions would you used to communicate with another Q series PLC if using serial and/or ethernet? I am going to make our controller look like another Mitsubishi PLC. What data frame or type would you use? I was thinking frame/tyoe 4C is the best because it is binary and faster. Is there any reason to choose another frame or type?

[waynes 8]

Hi Peter Nachtwey, I have used the Mits Q ethernet card before in binary and ascii modes. The binary mode is much quicker than the ascii mode. If you are going to spend the time then binary would be the best. The one option that I do like about the QJ71E71 module is the fact that you can set it up to establish an 'Active' connection to another PLC on a specified port. I cannot recall what the exact command were to send the data across, but it works like a bomb. Why mimic the Mits unit???

[panic mode 246]

i didn't have to write explicit messages in Q but manual for ethernet card should have it all. in the older QnA and A plcs writting to another controller using unsolicited message would go something like this: mov k31 d2000 ; unsolicited command length mov h401 d2001 ; pc number and command code mov k0 d2002 ; WDT (not used) mov k309 d2003 ; write to 309-th element (D309) of target controller mov h0A800 d2004 ; write to "D" type device (D309) mov k24 d2005 ; length of device starting from D309 BMOV D1006 D2006 k24 ; load the actual data to be sent BMOV U16\G1664 D2000 k24 ; transfer whole message to eth. card buffer SET Y160 ; and send... (reset it when ACK received) as you probably already know, ethernet card in this example was at address 0x0160. hope this helps...

[Peter Nachtwey 15]

Wayne, my company makes motion controllers that interface easily to most PLCs but Mitsubishi is not one of them. If we succeed in making our motion controller look like another mitsubishi PLC then we should or will be compatible with most Mitsubishi products. That is the hope anyway. Our product does a pretty good job of looking like a SLC5/05 when talking to AB products. Our product shows up on RSLinx as a SLC5/05. This chameleon approach makes it easy for the integration in customer's systems. panic mode, it is too bad Mitsubishi couldn't have something simple like a message block to hide most of the setup code. Is there a way to make a function block for this so the user could just provide a source, destination and length and the block returns an ENable, DoNe, and ERror bit like a AB MSG block? It looks like there is a small header at the front of the message that is 6 words long. I can'tsee where you selected between binary and ascii mode. How does one tell if it is done? I was reading the communications manual I download from this site. It say I should be using a FROM and TO block. Is that a Q only feature? Right now I only have a RS232 serial card. I will work on Ethernet later.

[panic mode 246]

Peter you can use TO and FROM. this is compatible with ALL mitsubishi plcs. i prefer to use mov instructions because of shorter format and you can comment buffers as well (you cannot comment them if you use TO or FROM). this is supported by QnA and Q plcs. to make above code compatible with A plc for example one would have to change last BMOV instruction to something like: TO h16 k1664 D2000 k24 Mitsubishi has very powerfull instruction set. In fact there are several manuals just for instructions. Look for dedicated instructions, there might be something to address this. The IEC version of GX Developer might do this for you. This code above was something I was using long before Q was known on this side of pond and documentation was not easy to find. I understand wish to make program look neat and tidy but I don't see a problem with few instructions for something like this. It's not that one would need to make thirty different versions of it like when doing math with AD PLCs. One block of code above is all it takes. It is enough to trigger it again when message content is updated.

[panic mode 246]

you need to understand how mitsubishi special cards work. plc has some memory and every special card has some of own memory. (special = everything other than simple digital I/O) part of special card memory that can be accessed by plc program is called buffer. each special card also has some i/o that are mapped to plc i/o range (I/O signals). in example above, eth card was using I/O range 0x0160-017F (most special cards use 32 point I/O). I/O signals are used for quick access to important (more frequently used) functions such as init request, error, send trigger, send complete etc. buffers are used to cover the rest. accessing buffers is slower and it should be kept to a minimum to keep low plc scan time. in example above whole message was arranged in plc memory and then with single instruction transfered to eth. card buffer. you can use I/O as much as you want since it's much faster than buffer access. once the buffer has everything, one simply triggers matching I/O to send it (Y0 or in this case Y160 because cards base address was 0x0160). in case message was not received or connection was lost etc. one or more of inputs in I/O range will change state. for example X18 (or for above example that would be X178) is "open end" error. send complete is X0 (or X160 in my case) and send error is X1 (or X161). Channel Open is X10 (X170), etc.

[Peter Nachtwey 15]

I have not figured out how one specifies the frame type for the MC protocol. I am looking into the BIDIN and BIDOUT blocks. Has anybody used BIDIN and BIDOUT before? They look simpler. I am looking at the documentation SH_NA_080006-J.pdf for the QJ71C42. It doesn't even mention TO and FROM blocks yet I see them referenced in other documents. WTF?

[panic mode 246]

Peter, I understand your frustration and I feel your pain but... I must admit it's always fun to see someone else struggle a bit with Mitsubishi, so please forgive me for this smile... Ok, back to the problem, I never used BIDIN or BIDOUT instructions and according to manual they have some limitations (like only apply to bidirectional protocols). TO and FROM are old way of doing things and shouldn't bother you. They are older and hence compatible with every Mitsubishi PLC. Lot's of new instructions/features doesn't apply to older families. I could see myself try using MOVs and BMOVs to create 4C frame as seen in 5.1.4 if nothing else than for testing although there are BIDIN examples in the manual (like 7.1.3).

[panic mode 246]

as for frame setup, see Chapter4 (settings and procedures prior to operation), see page 4-16 ([97 of 366])

[Peter Nachtwey 15]

I am actually almost done with writing the MC protocol. I am using 4C format 5. The data link layer part is simple. The application layer part is a little confusing. I was hoping to use our communication analyzer to see what is being sent back and forth to clear things up. However, it is the figuring out how to get the Mitsubishi to talk. We are going to try a loop back test first. The PLC should be able to talk to itself. This way we can test the PLC side first and make sure it works before testing our embedded code. There is no point in trying to debug two things at the same time. I just hope the customers are going to be able to figure out how to read and write using a QJ71C24. This definately calls for a good application note with example ladder program. I glad that someone is enjoying this. I will check out the chapter 4 in what document?

[panic mode 246]

Chapter4 of SH_NA_080006-J.pdf but it seam you already found that you need 4C format 5.

[Peter Nachtwey 15]

I think I am missing the big picture. Our controller has addressable registers in the range of 0-65535. I would like to have these appear as D0-D65535 to another Q series PLC. 1. Is buffer memory the same as PLC memory or is buffer memory on the QJ71C24. 2. If you wished to read register memory from another PLC would you read a buffer or read a device? i am calling the tech support tomorrow. There is a lot of info with no description as to how all the parts work together. :(

[panic mode 246]

that would strip the other PLC of big chunk of memory, some netork mechanisms in mitsubishi world already do what you ask but on smaller scale (2-8 registers per controller for example) and for transfer of bigger blocks, one usually uses message or command.

[Peter Nachtwey 15]

The PLC typically only needs to access about 4K. Yes, that uses a lot of memory if the PLC has only 12287 registers. What modern PLC has only 12287 registers. Our new motion controller has 32MB. We couldn't find memory any smaller. I am not getting anywhere with the PLC programming part. The person who said he would write the PLC side has given up. He couldn't even get an HMI ( Proface ) to access the QJ71C24. My comm analyzer said the Proface was not sending the right Frame ID. The right FrameID is 0F8H. The FrameID sent is 0FCH. Not good. The FROM and TO commands look simple enough. We just don't know where in buffer memory we should reading and writing. At least we have the serial port sending responding by sending error messages. If have a lot of questions about the Station No to last station no. I also have question about the response to a write. The documentation just indicates it with a *. I have talked to two people at Mitsubishi. None has a clue yet. Hopefully I will talk to someone tomorrow. Mean while the days are ticking on my demo GX developer. I am going to have to install it on another laptop. Can a HMI access PLC D memory without a ladder program? Can the QJ71C24 DMA into PLC memory? I haven't got answers to the most basic questions.

[panic mode 246]

I don't know. I never used it. What is status of this development do far? Did you manage to establish any type of connection with this card, even if it is in one direction only?

[Peter Nachtwey 15]

Break through! We can communicate with the PLC if the message is initiated from an external device ( realcomm ). We can monitor the data transaction with our comm analyzer. If have learned from this that I have a few corrections to make in my program but I shoukd be able to communicate with the PLC Monday. The data we send to the PLC has a FrameID of 0F8H. We don't understand why the OPC wants to send 0FCH. I think we can make it work. I am PI$$ED because the tech support can't answer the simplest of questions. and the documentation is poor. AB is worth the extra price. It is much easier to use. We have had to struggle by learning by trial and error. WTF is an objective PLC? I have seen that in the documentation. We still have not been able to initiate and receive complete messages from the Q PLC. We should be able to make much more progress on Monday. I will let you know what we come up with. I will post the program on this site. No one should have to suffer through this.

[Peter Nachtwey 15]

Well I am really PI$$ED now. All I have got so far is read this manual or read that manual. The problem is that I DON'T WANT TO READ ALL THEIR F$$KING manuals. I should only need to read the ones that apply to what I want to do. That shouldn't take more than one because what I want to do is not that hard. I still haven't found out of a Q PLC can initiate a Frame 4C format 5 message. I know the Q PLC can respond to frame 4C format 5. If a Q PLC cannot initiate a frame 4C format 5 message then I have wasted my time writing code for the MC protocol. I should be looking into the BIDIN or BIDOUT commands. I still haven't figured out why the FrameID the OPC sends is 0FCH instead of the 0F8H as documented. It has been two weeks and I still haven't talked to anybody at Mitsubishi that knows the big picture. This is sad and frustrating.

[panic mode 246]

Hi Peter, Did you read the very beginning (Overview) of the MC Protocol manual (SH_NA_080008-G)? It states that this protocol is only initiated by External device and PLC only replies. To communicate between two PLCs for example, you would need different protocol (like in ethernet example I posted).

[Peter Nachtwey 15]

I did read that and no it doesn't. It just says that the MC protocol is what is used by external device. I did ask if that means the PLC CAN'T use MCProtocol to talk peer to peer. I am still waiting for an answer all though am beginning to suspect you are right. The Q PLC can't use MC Protocl for peer to peer communications. At least not with a serial card. I do have the Bi directional protocol working. It was rather easy. It took less than one day. I could have saved two weeks if the tech support could only come up with some strategic answer but no. The problem with the Bi direction protocol is this: 1. An HMI can use Bidirectional protocol to communicate with our controller. This is the main reason I didn't want to use it. 2. There is no provision for multidrop. 3. Error handling is not well defined. 4. retries, time outs etc are not defined. 5. It would take a whole lot of code to add retries, timeouts. These things are all very simple in a AB MSG block. I would fire the person that designed the serial instructions for the Mitsubishi PLC. I would fire the tech support. The point is that I didn't need to read the MC protocol to make the Bi Directional protocol to work. I did not need to know the buffer locations inside the serial card. I did not need to know how the TO and FROM instruction work. A lot of grief and aggravation could have been avoided if the tech support could have just told me to use the Bi directional protocol because the MC Protocol would not do what I wanted to do. They just wasted my time and pi$$ed me off and I still haven't got the answers I thought I needed. I don't care about FrameIDs now, actually I never should have had to care.