Rocinante8

Is there any documentation on the .qpg (sequence program file) file format? I can copy the files from the PLC to my computer but I'd like to be able to programmatically import/export them as text files. So I can better compare what changed. I probably could reverse engineer the file format but it'd be much quicker if it was documented somewhere Thanks, Jeff  

Turns out the values are memory addresses so there's another command to read/write. All good now.

I'm trying to read the accel/decel values from the watch window in GX Works (actually I'm trying to read them from my computer code but if it works in the watch window it should work in my code). I can set the values such as MOVP K500 U0C\G142 in the program, but how do I determine the device type (X, Y, D, etc.) and the address. Thanks, Jeff  

I have a project where I have to read I/O, and potentially initiate programs on the Mitsubishi PLC. Seems I can use the Melsec Protocol but I have some difficulty getting started. I can communicate via Ethernet using GXWorks 2 so hardware-wise there shouldn't be anything wrong. I'm using QJ71E71, Q06HCPU, QX42, etc. Initially I open a UDP socket to the correct IP address and port (copy the port from GXWorks) and attempt to issue a request 3E/Binary, specifying the network, PC, Module IO, and station and it always times out. Is there any source code that just does a basic read of a memory location? I'm using C++ but I should be able to understand any code sample in VB, C, C#, or others. Also, is there any issue with multiple connections to the PLCs. Right now I quit GXWorks before I test but is this necessary. Thanks, Jeff

Thanks Jeremy. Got things working late last Friday. The default UDP port is 5000 but sometimes I have to use 5001 or 5002 (maybe other copies of GX Works are running on other computers). It turns out a lot of the values are essentially fixed; e.g. GX Works shows the network as Network 1 but I have to  use Network 0. Module I/O and Module Station are similarly fixed. I'm still not sure what counts as a 'module' in PLC parlance, is it an individual unit plugged into a slot or is it a collection of units plugged into the backplane? I'm still working on adding to my driver but I can do DI, DO, AI, AO so the basics are covered. When I'm done I will publish my code somewhere in case it can help others.   //read DI  route.byNetwork = 0;  route.byPC = 255;  route.wDestinationModuleIO = 0x03FF;//0x03e1 can also work  route.byDestinationModuleStation = 0;  request.wDataLength = 12;  request.wCPUTimer = 10; //0 = infinite wait; time = 250ms*x (4 = 1 second)  request.wMainCommand = PC_BatchRead; //0x0401  request.wSubCommand = 0x01;//0 is word; 1 is bit  dwAddress = 0x21;// head (starting) device number  request.abyAddress[0] = reinterpret_cast<BYTE*>(&dwAddress)[0];  request.abyAddress[1] = reinterpret_cast<BYTE*>(&dwAddress)[1];  request.abyAddress[2] = reinterpret_cast<BYTE*>(&dwAddress)[2];  request.eDeviceType = PDT_X_Input; //0x9C  request.wDevicePointCount = 0x1; by = byte, w = word/2 bytes, dw = double word/4bytes, e = enumeration/1 byte. The reason I have the address like this is because there are no 3 byte numbers in C++. Intel PC and PLC are little endian so the least significant byte goes first   //return message from PL; in this case the data length will be 1 so there will be 1 additional byte that shows the digital state. It seems like the PLC can show 2 bits per byte so 0x10 would be first bit on, second bit off (or unused), 0x11 would be first and second bits on. struct SResponse {  WORD wResponseDataLength;  WORD wCompleteCode; };    

Thanks to help from Mark and others I've gotten a little further in that I can get a reply. Unfortunately the reply is always 0x0403, which I found defined as "The number of devices used in the process control instruction is incorrect." Below is my setup. QX42 should be digital input and from GX Works I can see that X21 is high. [Slot] [Type] [Model Name] [Point] [I/OAddress] [CPU] [CPU] [Q06HCPU] [-] [-] [0] [Intelli.] [QJ71E71-100] [32Point] [0000] [1] [Input] [QX42] [64Point] [0020] [2] [Output] [QY42P] [64Point] [0060] [3] [Intelli.] [Q68ADV] [16Point] [00A0] [4] [Intelli.] [Q68DAVN] [16Point] [00B0] [5] [Intelli.] [QD70P8] [32Point] [00C0]   To read it I fill in the following structure:   request.wFramType = 0x50; //3E   request.byNetwork = 1;   request.byPC = 255;   request.wDestinationModuleIO = 0x20;   request.byDestinationModuleStation = 2;   request.wDataLength = 12;   request.wCPUTimer = 0x10;   request.wMainCommand = 0x0401;   request.wSubCommand = 0x1;   dwAddress = 21;   request.abyAddress[0] = reinterpret_cast<BYTE*>(&dwAddress)[0];   request.abyAddress[1] = reinterpret_cast<BYTE*>(&dwAddress)[1];   request.abyAddress[2] = reinterpret_cast<BYTE*>(&dwAddress)[2];   request.eDeviceType = PDT_X; //0x9C   request.wSize = 1;   I'm not sure what Destination Module IO, Destination Module Station, and Address represent in the structure. Thanks, Jeff                                                                                

Thanks for the feedback. I'll take a look at MX Components to see if that can work. My company is an OEM of capital equipment so if it's a per unit license that wouldn't be ideal. Looking at the manuals the Melsec protocol seems simple enough but it would be nice to see a working example to compare my code to. Jeff