DWIM

I must say, we need IO-Link in 2m distance from the PLC, so CC-Link to Baluff is an expensive solution for 2 meters.

Thank you for sharing your thoughts. I see, I must change the platform as it seems. Nobody here in our area uses Mitsu (hard to find skilled people) and on top of that no connectivity... If we change the product, we can also change the manufacturer.

Hi everybody I had the same error message as initial poster  : The target was a FX3-G. I needed more memory so I modified: Navigation=>Project=>Parameter=>PLC Parameter=>Memory capacity After that I had this error. The solution was to go to Menu=>Tool=>Clear all Parameters. Maybe the settings on your PLC are lost! I didin't tested that.

I have library from Mitsubishi which uses inside "EthernetComm"  Function block and inside this, it uses SP_SOCOPEN  and SP_SOCCLOSE functions Oh, I'll check the states of the SP_SOCxxx functions in their data structure they use...I have now a 12hours workday behind me...my family already called me.  I look into it at best on Sunday. Thanks so far for your help. FX5ModbusTCP_GW3_V100 Version 1.00 - Function block that offers Modbus TCP/IP Client functionality on a FX5-series  PLC system  with a built-in Ethernet port. Created in GX Works3 - 24 May 2016 Function block supports the following CPU-types: FX5-series.    

No, i think. There is a workaround: Define an array as VAR ==> CONST_LABEL1  (Uppercase indicates in programming a constant) Define each constant as single entity at position 2,3,... in the dialog of your picture ==> CONST_LABEL_1, CONST_LABEL_2 At startup move these constants to the var. Rule: Do never overwrite in your code anything which has all UPPERCASE.   

Thanks for your reply! Yes, there is some information. Mostly about added functions/modules. They have no bugs in the firmware! Clever Japanese engineers....  OK, I would also not publicly admit it ...;-) MODBUS: I tried to connect to MODBUS TCP IO boxes (25 stations). I was astonished to see, that it takes seconds (!) to check/write the IO states of all of them! Welcome in 2020! Yes, seconds I tell you...honestly, not milliseconds! After looking in the mirror I saw the person who bought this technology..... Then I found a reconnect delay in the Mitsubishi library. I could lower it from 800ms (if I recall correctly) to 150ms with a more or less reliable connection. This improved things a little bit. Still very sluggish. Smart me thought: Well, let the PLC use two of its eight ethernet connections simultaneously! So I made: Group1: 12 boxes on ethernet channel 4  Group2: 13 boxes on ethernet channel 5  Now, after all code in place, it connects for a while happily on channel 4 (Group 1) while channel 5 is in "connection opening" state. Then suddenly, an electron moves, and it starts working for a while on channel 2 (Group 2) while connection 4 is waiting in "connection opening" state. I found no pattern, unfortunately. And a lot of hair pulling didn't helped either...... It should be possible to connect on two connections simultaneously, not?  

Hi I have a wiring issue. As you Mitsu users know, many PLC's have on each side these two screw rows, one higher and the other lone ower for inputs and outputs. Our wiring expert connects wires by crimping some pipe style shoes with a sleeve (don't know the exact english word) . So far so good. The problem are the mounted wires on the upper "stage" . They cross the beneath screw eaxctly in the middle of their head. Our service technicians come to me and complain about having to remove the upper wires to access the lower screw. This is even more the case if the upper screw has two wires attached. I saw in a Mitsu Manual a nice drawing, where they use a fork terminal or even two on each other, so the wire is exactly centered over the ridge between two lower screws, leaving the lower screw exposed. Does anybody has a place where to order these narrow sleeve fork terminals? Our distributors have only this car-style (=> large, thick) standard crimp shoes. They are so wide, the lower screw is covered again. Thanks for any tips!

IO_Rack: Thanks for the link! Interesting stuff there:  STRIPPED CHAIN TERMINALS ...Iooking for this crimp gatling gun...:-) Ron_S: It is not a big problem. It happened. Yes a rare event. I always look around for improvements. 

Bitsn Bytes: The link you showed got me an idea what I've seen in the Mitsubishi document. ==>Non-insulated fork terminals! If we take the insulation away, then their backside is flat, and one can put two onto each other by flipping one over. But...but..if the top row is connected with these non-insulated terminals and the service man wants to fiddle with his screwdriver between them to access the lower screw...nähh...I'll pass on this one. It seems on paper, ideas are always good...

Thanks for your reply. But I disagree. The wire is inline with the pin.Agreed. But then one has to mount this pin at an offset of the top screw. So, the pin and the wire go straight over the lower screw. Because the lower screw has an offset too.  In short: I'm looking for a small flat fork terminal. Those available here are gigantic, made for cars or bulldozers with high currents.

Hi I would like to know how to turn of COM.ERR LED on FX3GE PLC. If somebody has a tip, would be great. The FX3GE has, according to the documentation, a FX3-ENET-ADP module built in. Our setup: We have a FX3U as master and four slaves FX3GE. FX3U->FX3-ENET(Ethernet Module)->Ethernet switch -> Four FX3GE PLCs The code in FX3U reads and sends data with the library from Mitsubishi. Basically, it works, but out of nowhere there is an error 2558, Command block x00BF. And the LED is on. We have no malfunctioning on the machine. Subsequent commands/data get through. So, how do we clear the error LED? I have now read many documents and could not find a solution. It works in GXWorks2. There is a button on the "network diagnostic" dialog. But I cannot sit all the time at the customers site to manually clear the LED. It would be of course better, if no error occurs, but I was unable so far to find the correct settings. For example there are many timing settings on the FX3-ENET module to be set with FX Configurator. But I could not find the timing settings for the FX3-ENET-ADP and the help file  of the library says they should match. Further, what do you think, is it ok to run the library code to communicate with 4 PLC's unsynchronized? The master powers up and starts communication with all four slave PLC's at once. To be correct, I'm new to PLC's and don't know the exact execution time of the code/ladder blocks. But I found no synchronization mechanism only four times the same blocks with different IP's / ports fed in. It seems to me they run at more or less arbitrary time and with delays on the network...well....there may be interactions. Any tips or ideas are welcome!