Connection Timed out

[Dhruva0707]

Hey, I can set up the connection with the device on an specific ipadress and port (5556).
However,
I get an error mentioning 'Timed out' as can be seen from the screenshot

My code is displayed as well.

Let me know if this is an issue with the PLC configuration or improper addressing of the data.
Test.txt

[Dhruva0707]

Device in use is FX3GE-24M.

The code is as follows:
var mc = require('mcprotocol');
var conn = new mc;
var doneReading = false;
var doneWriting = false;

var variables = { TEST1: 'D0', // 5 words starting at D0
TEST2: 'M6990,28', // 28 bits at M6990
TEST3: 'CN199,2', // ILLEGAL as CN199 is 16-bit, CN200 is 32-bit, must request separately
TEST4: 'R2000,2', // 2 words at R2000
TEST5: 'X034', // Simple input
TEST6: 'D6000.1,20', // 20 bits starting at D6000.1
TEST7: 'D6001.2', // Single bit at D6001
TEST8: 'S4,2', // 2 bits at S4
TEST9: 'RFLOAT5000,40' // 40 floating point numbers at R5000
}; // See setTranslationCB below for more examples

conn.initiateConnection({port: 5556, host: '192.168.1.250', ascii: false}, connected);

function connected(err) {
if (typeof(err) !== "undefined") {
// We have an error. Maybe the PLC is not reachable.
console.log(err);
process.exit();
}
conn.setTranslationCB(function(tag) {return variables[tag];}); // This sets the "translation" to allow us to work with object names defined in our app not in the module
//conn.addItems(['TEST1', 'TEST4']);
//conn.addItems('TEST6');
conn.addItems('TEST1');
// conn.removeItems(['TEST2', 'TEST3']); // We could do this.
// conn.writeItems(['TEST5', 'TEST7'], [ true, true ], valuesWritten); // You can write an array of items as well.
//conn.writeItems('TEST4', [ 666, 777 ], valuesWritten); // You can write a single array item too.
conn.readAllItems(valuesReady);
}

function valuesReady(anythingBad, values) {
if (anythingBad) { console.log("SOMETHING WENT WRONG READING VALUES!!!!"); }
console.log(values);
doneReading = true;
if (doneWriting) { process.exit(); }
}

function valuesWritten(anythingBad) {
if (anythingBad) { console.log("SOMETHING WENT WRONG WRITING VALUES!!!!"); }
console.log("Done writing.");
doneWriting = true;
if (doneReading) { process.exit(); }
}

[plcpeople]

Can you please edit mcprotocol.js on line 38 at set effectiveDebugLevel to 99 instead of 0, and re-post the output from running your code after that? Also, please post your Ethernet configuration from GXWorks2, this could be something really simple, like ASCII/binary mismatch.

I haven't tested with an FX3GE but everything I read suggests it should work no problem.

[Dhruva0707]

I managed to get it working. Apparently there was a fault in the plc and it had not changed the port to the one I was trying to connect on. Thank you so much for your response! And happy new year

[Dhruva0707]

Rebooting the PLC helped resolve the issue.

[strifel]

Hi. I do have the same problem. I restarted the plc twice, now.
(First one yesterday after enabling mc protocol, second a minute ago.)
I get the following log:

[113686,804507057] Initiate Called - Connecting to PLC with address and parameters:
[113686,809687666] { port: 5555, host: '192.168.1.101', ascii: false }
[113686,811234426] Connection cleanup is happening
[113686,811340820 192.168.1.101] Clearing read PacketTimeouts
[113686,811418750 192.168.1.101] Clearing write PacketTimeouts
[113686,812222591 192.168.1.101] <initiating a new connection>
[113686,812269960 192.168.1.101] Attempting to connect to host...
[113686,821674644 192.168.1.101] TCP Connection Established to 192.168.1.101 on port 5555
[113686,822028337] Translation OK
[113686,822177118 192.168.1.101] Reading All Items (readAllItems was called)
[113686,822375138 192.168.1.101] Adding or Removing { arg: 'TEST7', action: 'add' }
[113686,822480119 192.168.1.101] Adding TEST7
[113686,824293375 192.168.1.101] Clearing read PacketTimeouts
[113686,824596618 192.168.1.101] Calling SRP from RAI
[113686,824790260 192.168.1.101] SendReadPacket called
[113686,824972343] We're Binary
[113686,825341349] The Returned MC Buffer is:
[113686,825383893] <Buffer 01 ff 0a 00 50 00 00 00 20 4d 01 00>
[113686,825706028] The returned buffer length is 12
[113686,825778777] The final send buffer is:
[113686,825817981] <Buffer 01 ff 0a 00 50 00 00 00 20 4d 01 00>
[113686,826471331] Sending Read Packet SEQ 2
[113691,329933460 192.168.1.101] PacketTimeout called with type read and seq 2
[113691,330120987 192.168.1.101] READ TIMEOUT on sequence number 2
[113691,330538253 192.168.1.101] ReadResponse called
[113691,331107548] Timeout error - zero length packet
[113691,331301488 192.168.1.101] Read Time is 4 seconds and 506.4 ms.
[113691,331692247 192.168.1.101] Every packet done sending
[113691,332382148] Item Quality is Bad
[113691,332467814 192.168.1.101] Address M91 has value false and quality BAD 255
[113691,332615472 192.168.1.101] We are calling back our readDoneCallback.
SOMETHING WENT WRONG READING VALUES!!!!
{ TEST7: 'BAD 255' }

I do use the example without writing but with an Address I know exists.
MC Protocol is activated TCP port 5555.
Device is a Q-Series with built in Ethernet.
Any help would be appreciated.
Thank you

[plcpeople]

Has the PLC ever responded at all? It looks like node is sending it a packet but getting nothing back. Can you post a pic of the Ethernet configuration in the Mitsubishi software?

[strifel]

Hi. Thanks for trying to help me.
I do not know if it responds at all. I know that I can use the Debug Tool in GX Works 2 so I assumed that.
Also the PLC responds to my pings.



I hope I even took the right number as adress. But I tested a few (what i think to be) adresses and nothing worked.

Thanks

[plcpeople]

It looks like it should work. What is different between this and when you first reported the issue in January, when it was resolved by cycling power? It looks like the PLC just is not responding at all.

[strifel]

I was not the one reporting this issue in December/January

[plcpeople]

Sorry, I am not sure how I misread that but it's obvious now.

What is the model of CPU? I don't have a Q series, but other users have reported it to work with no issue. Maybe only certain models of Q support the 1E frames used by this driver? But I thought from earlier reading that they all did. Do any other HMI applications talk to this PLC, or are there any others you could try?

[strifel]

Its a Q06UDEHCPU.
There are two GOTs connected.
Also watching of the variables does work in GXWorks2
But over MELSOFT Connection I think.
I do not know what else I could try.

Also: It's not like it isn't answering at all:

[plcpeople]

I am not sure what else to say on this. It seems like everything is set up right but the PLC just is not answering. My only other suggestion would be to try ASCII instead of binary.

[plcpeople]

I had a look at a few more manuals and according to this the QnU PLCs may only support them with newer serial numbers. So unfortunately I think that is why it worked for one user with a different Q CPU. (It would help if I was a Mitsubishi expert, but I'm not)

One manual says this:

and another this

I am curious how your serial number compares to these. But since everything else looks right, yours almost certainly does not support these frames.

[strifel]

Sorry for the late awnser.

I just checked my Serial Number and it starts with 12.
So its later than the first Requirement, but not later than the second.

Is there any way I can get this to work. Are the protocols that different or could I possible get it to work with little changes.

Thanks a lot for all your help

[plcpeople]

I think the only way this will work with your CPU is if we add support for 3E frames. (Or another type, but 3E looks like it would support the most additional CPU types). I would be willing to do a bit of work on this but I don't have a test CPU other than an FX3U so I think the only way we could make this work is if someone else had some time and a test CPU to help get it working.

[strifel]

Sorry I could have updated the Issue.
I got it working after a lot of tries with some strange undocumented japanese c# library which uses 3E Frames (I think).
Its not the best solution (as I have to run it on Windows) but it works for now.

Thanks a lot for trying to help me.
If you want to implement anything and need someone testing it on a Q-Series I would be glad to assist.

[plcpeople]

OK I pushed a new version to the repository (but not to npm), and it seems to send the right packet in both ASCII and binary to read device memory using 3E frames. To activate the new code add connection options frame: '3E' and it would help if you added debug: true as well.

Use care in testing on a real PLC. I've tried to be careful but I have no way of testing these frames on a real CPU.

[strifel]

Ok. I tested it and it didn't work.
I tried reading a value I know exists in the M register. (I used more or less the sample code and added the frame parameter)

[107578,602483036] Initiate Called - Connecting to PLC with address and parameters:
[107578,607831786] { port: 5555, host: '192.168.1.101', ascii: false, frame: '3E' }
[107578,609338109] On Frame 3E // I added that message to check if I really use the right version :)
[107578,609482925] Connection cleanup is happening
[107578,609578440 192.168.1.101] Clearing read PacketTimeouts
[107578,609660252 192.168.1.101] Clearing write PacketTimeouts
[107578,610672564 192.168.1.101] <initiating a new connection>
[107578,610723102 192.168.1.101] Attempting to connect to host...
(node:67838) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[107578,620175947 192.168.1.101] TCP Connection Established to 192.168.1.101 on port 5555
[107578,620534004] Translation OK
[107580,624759748 192.168.1.101] Reading All Items (readAllItems was called)
[107580,625180843 192.168.1.101] Adding or Removing { arg: 'TEST7', action: 'add' }
[107580,625386708 192.168.1.101] Adding TEST7
[107580,627368603 192.168.1.101] Clearing read PacketTimeouts
[107580,627564088 192.168.1.101] Calling SRP from RAI
[107580,627854844 192.168.1.101] SendReadPacket called
[107580,628333429] We're Binary
[107580,628648458] The Returned MC Buffer is:
[107580,628705273] <Buffer 50 00 00 ff ff 03 00 0c 00 10 00 01 04 00 00 e0 03 00 90 01 00>
[107580,629148770] The returned buffer length is 21
[107580,629235520] The final send buffer is:
[107580,629282756] <Buffer 50 00 00 ff ff 03 00 0c 00 10 00 01 04 00 00 e0 03 00 90 01 00>
[107580,629581298] Sending Read Packet SEQ 2
[107585,134118887 192.168.1.101] PacketTimeout called with type read and seq 2
[107585,134299142 192.168.1.101] READ TIMEOUT on sequence number 2
[107585,134921665 192.168.1.101] ReadResponse called
[107585,135480931] Timeout error - zero length packet
[107585,135677415 192.168.1.101] Read Time is 4 seconds and 507.7 ms.
[107585,135997639 192.168.1.101] Every packet done sending
[107585,136687576] Item Quality is Bad
[107585,136777957 192.168.1.101] Address M1003 has value false and quality BAD 255
[107585,136955279 192.168.1.101] We are calling back our readDoneCallback.
SOMETHING WENT WRONG READING VALUES!!!!
{ TEST7: 'BAD 255' }

For me this seems like nothing has changed (which I think is strange)
For reference: I used a library with success to connect over 3E Frames

[plcpeople]

The packet in your log looked correct even when re-reading the Mitsubishi documentation, so I downloaded the library you linked and requested M1003 through it as well. The packet it sent out was nearly identical, with only a slight difference in offset, so I think something else is different on your end between the NodeJS and the C#. Is there any way you could post pictures or a log of a Wireshark trace of the working C# program as well as this library not working from the same computer? It just seems really strange that the PLC would allow the connection, but wouldn't send any reply packet at all.

[strifel]

I thought I will update the issue.
I have not had a lot of time, but I tried it.
I somehow do not get the c# program working on the computer where I have dotnet,. wireshark and node installed.
I will try debugging that in the next few days