The vendor for some of our machines added Ethernet modules to their PLCs. Supposedly, that should have allowed us to extract data from the PLC.
After we checked on the machines, we found out the PLCs have only a local IP with no gateway, so they can't be reached from outside. The ethernet modules can be pinged from the outside, and in theory they can handle the MC Protocol, but when I go to the Ethernet configuration, I only see options for MELSOFT, Active and passive, but not for MC protocol (despite having enabled the "Online change" option).
Thanks for the reply and sorry for the delay, I've had a few extremely busy days...
The PLC is a L06CPU, the Ethernet module is an Ethernet/CC IE Field adapter.
I made a PDF with the PLC and Ethernet module configuration: PLC CONFIG.pdf (149.5 KB)
The main issue I see is that the PLC is using an internal IP (no subnet mask, no gateway) to communicate with the HMI, but only the Ethernet module has an external IP supplied by IT. The PLC allows for MC Protocol, but the Ethernet configuration can't be set in MC protocol as is.
From experience of very VERY flaky Mitsi comms, I strongly recommend your first attempt is with UDP MC Protocol` and set the port number around 3001 ~ 3008 DECIMAL (be careful, mitsi stuff often uses hexadecimal numbering) All I can say is thank god I dont have to deal with mitsi stuff any more. Compared with OMRON, IMO, mitsi PLCs and software are a steaming pile of dog poo!
Also, if the PLC supports it, chose 4E frames as these support ID/Seq numbers in the data and are a better protocol for data integrity.
We don't use the built-in Ethernet config because it doesn't have an external IP/subnet/gateway. The Ethernet/CC IE Field module has a different config, with an external IP, subnet, etc. and is hooked directly to the factory internal network (unlike the PLC). On the same file, towards the end, there's the Ethernet/CC IE field module config:
Theoretically, according to the vendor, the PLC needed that module to connect to the network (they charged us for it, then sent a maintenance guy to install it and do the basic config (but he had no idea about networks or IT, just went by the rotes).
In theory this should allow to get the data as "plug and play" as possible, but I'm starting to suspect they did a half-assed job so they could send another guy to do the proper configuration (and charge us again for it).
I have a bit of experience with Mitsubishi FX5, and it seemed simpler and more straightforward than this one (I used GXWorks3, not GXWorks 2, like on this case). Lately I've been using Siemens PLCs and they're not good, either.
If I had to design machines, I'd probably use raspberry pi-based PLCs that can run node-red directly, or, incase the machine has a FANUC robot like many of our own, hook up digital I/O to the robot and program the logic in KAREL (FANUC's own language, based on Pascal).
Since Mitsi change the layout of this in pretty much every generation of PLC, I was unsure if it had passive/procedure exist options.
Since it does have "passive" "proceedure exist" (seriously, what kind of names are those!!!), my strong recommendation is - fill up them empty spaces because it WILL lockup and you WILL want an alternative (fall back) open port to use until you have the maintenance window to power cycle the PLC. I had 15 years of this!
If this were my facility, I would simply pull the config, update the rows, push the config, restart the PLC and these are the settings I would put...
In that Ethernet/CC IE Field config, when you select UDP, it darkens the "Open system" field and you can't select anything. And if you go with TCP, the option to select "MC Protocol" does not appear on the pull-down list.
So in which case, fill them "MC Protocol" entries I proposed with a mixture of UDP and TCP Unpassive, Procedure Exist - which is essentially MC Protocol (thats what Procedure Exist means)
remember to chose different port numbers and be mindful of DECIMAL/HEXADECIMAL values.
EDIT - re-read.
So the CC card does not permit UDP + unpassive? That is nuts! Then try your luck with TCP (flaky city ahead - be warned, dragons be here)
PS: You can connect to the built in ethernet port, you just have to get the MC Protocol Config node set correctly. I think it is something like UDP Port 5000 or TCP 5001 (or vice versa - i forget)
In my case, I have a lot of parameters, some of them of the same type and sequentially written in the memory, but some of them are of different type and placed in entirely different places within the memory. Would you recommend to read a huge block of memory and parse everything in one go, or do you think it's easier to read the parameters using 2-3 buffers?
If you have ever seen any of my post about data collection from remote controllers (PLC / industrial / otherwise) you will often see me bang on about "data consistency" - i.e. getting EVERTHING you can in one go (from the same scan of the PLC).
The first benefit is less comms traffic - but this is more important in the case of mitsi PLCs whos comm stack is part of the scan!
The next benefit is crossreferencability (is that a word?) When you READ or WRITE from a PLC, it is imperitive your maintenace guys know you are reading/writing to an area from an external, non cross-reffable place. By putting all values of interest into one contiguous block, maintenance folk instantly get a cross ref of what & where is being collected/updated externally.
However, where this is most important is when data parts are relative. For example, imagine you are collecting "downtime timers" from a PLC
fault
runtime
waiting
exit full
totalStoppage
totalTime
and you read them individually, the fault time could tick 5 times before you collect the totalTime and therefor, summing the values gives you inaccurate data and your database now has bad data (SISO)
This is a shortened version of my rant but I will finish it by stating: ALWAYS try to minimise the number of poll areas to 1 if possible. If not possible, create a collection buffer in the PLC and have your ladder "push" values into the collection buffer & your Node-RED can read them out, at leisure, with zero inconsistencies. This also has the benefit of never losing data in the event of a comms outage or node-red restart (the buffer fills until Node-RED is back on line and collects the data).
PS, in my previous job, I did over 20years with PLC data collection, data sanitisation, accuracy checking etc etc.
The issue here is that the vendor has given us the software as is, and if we touch anything, off goes the warranty and the service contract (literally they won't come even if we pay for it).
If it depended on me, I'd have put everything sequentially on a single block, ordered by type from shorter to longer variables (bits, int16, int32, strings). But I have to work with what I have
