kaare_t

Not possible with your unit, see manual:

What PLC are you using? Which outputs are you trying to activate?

Sounds like noise problem, given that you are 100% sure that the bit-settings (databit/stopbit/parity) is correct. Try as a test to lower the transmission speed. I'm not aware of any issues with the FX5 and would guess a cable or setting issue... What is your peripheral device communicating with the FX5?

Regarding the number of I/O points, it refers to the maximum number of "I/O" (Inputs/Outputs), so 32 inputs and 32 outputs is the same as 32 I/O. That's not why you cannot get it to work though, but it's best to set it correct straight away. I think you should try to download the few lines of code to the PLC, just in case there's some initialization being done when transferred to the buffer memories. Try it, just as a test.

Hi and welcome as a poster! I have never used the module you are referring to, nor have I used S-Link, but according to the manual there's a little configuration needed to get the module working. I found a manual here: https://www3.panasonic.biz/ac/na_download/fasys/sensor/wiresaving/manual/sl-vmel-q_e.pdf?f_cd=3121 To your setup: First of all, it is a standard intelligent module with 32 I/O points (not 64 like you've used). It doesn't matter for the config you have, but it's best to set it correct straight away. Secondly, if you can read/write to the buffer memories then you're probably "almost there" (I would guess). The manual gives a small example in page 18, a bit of ladder code -> try that first. It also looks like you can configure some bus settings and/or node settings from page 23 in the manual, but I haven't read it in detail. As mentioned, I've never used S-Link or this module before, I just read quickly through the manual for the module and I'm referring to that. What does the inputs say? Does X0 (or in your case X60) turn on ("Unit Ready")? Is X1 (or in your case X61) turn on ("BUSY" - it means the module is booting or in config mode)? Does any of the error inputs go high (X10-X16 - or in your case X70-X76)?

There are built-in PID regulators in the FX5 series. Just search for PID in the instruction list, add it and press "F1" to get help using the instruction...

Nice to know! Thanks! Cheers!

I haven't really looked hard into your commands, but I think it is the following (you can verify it with the MC protocol manual, or FX manual): 02 - STX (Text Start) 0103C02 - Header and request ("MC" format) 03 - ETX (Text End) 6C - CRC or SumCheck You can find a manual for MC protocol here, it's covering Q-series, but also FX series: http://forums.mrplc.com/index.php?/files/file/1086-q_l-melsec-comms-mc-sh080008lpdf/

Doesn't EthernetIP broadcast all messages? Or is that a different brand? I don't remember exactly but there is one provider who recommends physically (and I mean physically - NOT VLAN tagging) separating the networks due to broadcast messages... Anyway: You say you loose connection between PLC and MES module, but the MES module is connected to the same rack as the PLC? Or are there two different racks?? If the same rack, you don't need to "communicate" between MES and PLC using Ethernet... I'm not into the U.S. definitions of the MES module, does "MES US" mean the CCPU controller with DeviceWise software loaded, or is "MES US" the QJ71MES96 module?

Asked and answered here: http://forums.mrplc.com/index.php?/topic/35520-fx-usb-aw/

Well, if you have a MES US module, I would highly recommend a "global" SNTP server for all units (GOT, MES and PLC all synchronizes with the global SNTP server). If you already have a MES module then you probably also have a DB server of some kind that can be setup to also be a SNTP server. P.S. SNTP servers don't broadcast timestamps. They are servers and receive time-requests from clients (like GOT/MES/PLC). But any Windows server or Linux server (or even a Windows computer) can be setup to accept and reply to SNTP requests.

Well, what happens if you try to switch on Y0-Y7 plus Y10? Won't Y10 work, or does Y0-Y7 go dark?

So if I understand you correctly, you can switch on 0-7 OR 10-17 OR 20-27, but not several "batches" at once?

To read clock data you need to use DATERD(P) which will output an array of INT's. Why your clock is 3 seconds out of sync is hard to say, but as long as your not synchronizing your PLC and GOT against a valid (S)NTP server it's a bit hard to say. Do you have a (S)NTP server available in your network, or only your computer?

I've never used MC Works, but how are you planning on communicating? USB? Ethernet? Serial?

@Gambit: My guess is that the topic starter builds machines/systems and delivers more than just one. That's why $1000 makes a different if you have 10 or 100 systems... I agree fully that Mitsubishi has great quality however adding another controller to an existing controller seems a bit too much "addon" to me when the topic starter clearly wishes to have an "embedded-like" system. I would rather recommend the topic starter to look into a fullblown PLC system for their application, and remove their existing controller. But then again, we don't know anything about what the controller is used for, so it's a bit hard to tell... @Ericw: Do you have the possibility to tell us more about your application and system-solution? Not that it's very important at this point, it would just be interesting to know... Btw, @Gambit: Do you know if MX Components supports CCLinkIE Field directly via an Ethernet port?

I do agree with everything you write and I understand your concerns. To be honest I think I would recommend you to get a servo amplifier that supports ModbusTCP directly. From what I know, Mitsubishi has released the CCLinkIE protocol for slave devices to partners, but only the "slave" protocol. You need the "master" to be able to control the servo amplifier. As a last effort, you could investigate in MX Components (classes for .NET, including examples for C#). I'm not sure if it directly supports CCLinkIE, but I think it does. I did a quick search but I cannot find a specific statement saying it supports CCLinkIE, but you could check with a local Mitsubishi dealer. Maybe it does...? I'm guessing this is a controller that will be used for several applications, so there's always an option to try and reverse-engineer the protocol if you have the resources and see a potential. I know there are Wireshark profiles for CCLinkIE Field, and you can always check out the CLPA (CC-Link Partner Association): https://www.cc-link.org/en/ I'm sad to say that maybe it will be easier and cheaper for you to choose a different brand than Mitsubishi in this case.

CC-Link IE Field is based on standard Ethernet, but I'm not sure if Mitsubishi releases the protocol specification. To be honest I doubt it. What type of controller do you have? Can you use ModbusRTU (which I think is built-in on the MR-J4)? Or a different option would be to use a gateway; use an Ethernet/IP servo amplifier and purchase an Anybus gateway: https://www.anybus.com/products/gateway-index/anybus-xgateway/detail/anybus-x-gateway-ethernet-ip-scanner---modbus-tcp-server There are several options, but if you could shed some light about your original controller it would be easier to give recommendations...

@KY WONG: Regarding CRC, you mentioned that you needed to write a CRC check in code. Why? In the "Predefined Protocol Function" , CRC is automatically applied to both outgoing and incoming messages (see last line in picture). You should re-enable CRC on your peripheral device, and also use CRC on the Q. I would recommend using binary encoding also.

If you get parity errors randomly, possibly with <null> chars in between, I would suspect wiring issues and possibly electrical noise. Are you using twisted pair cable with shield? What's the distance between the units and what's the full length of the line? Did you connect the ground and shield to all connected units? Did you apply the correct resistors in both ends?

Hi, So the error LED is lit no matter what you do?? Sounds like a bad unit...  If the online diagnostics says "No Error", then the error LED should be dark.

And in case you come across "K" instead of "H" you are dealing with a decimal constant... H = Hexadecimal, K = Decimal...

Sounds messy in my opinion... I know that E-Designer is pretty "old", and I haven't used it for quite some time but still.... That "solution" sounds bad...

Regarding this point it is not defined which CRC you need. I'm pretty sure that the built-in CRC are ment for the MELSEC protocol and not when using "NonProcedural Protocol". In other words you need to write the CRC yourself. I might have some examples written in GX IEC Developer or GX Works2 (don't remember). Also, the topic starter is using ASCII and not binary, are you sure you are looking for a CRC (and not a sumcheck)? @KY WONG: Which CRC do you need? Do you have a spec?

Most of your questions are related to the Modbus Mapping in the PLC, and not the actual Modbus communication... May I ask what your problem with the default mapping is? And why is it causing issues for you? Is your master expecting/demanding different or other areas when requesting information from the slave (FX3U)? I don't know why Mitsubishi chose to map the way they did. I've used ModbusRTU a lot and never really had a problem with the mapping...