FX3U ENET and Multicasting

[cadomanis 0]

Anyone done or tried to do any Multicast UDP comms with the FX3U-ENET. I am thinking that sending is probably no problem, but not sure how to set it up to receive. Any thoughts are appreciated.

[Dariusch 2]

Hi cadomains, If you use GX-IEC, here a funtionblock to make dataexchange Beijer- Functionblock for dataexchange FX3U-ENET Best Regards Dariusch

[kaare_t 155]

Can't say I've ever heard about PLCs and Multicasting, can I ask what you want to use Multicasting for??

[cadomanis 0]

I took a look at the help file on those function blocks and didn't see anything specifically about Multicasting? Did you have a specific example? This is for a single axis motion controller we have developed around the FX3U. We network these units into a larger multi-axis system, and I need to add some ability to have these units send out there current position and speed data. Rather than braoadcasting, I would like to use multicasting so as not to create a bad network flood. For the sending I think ti is no problem to use the typical No Procedure methods to send the data to a multicast address. What I am unclear on is how to handle the receiving? I guess I could just UDP listen on the correct port, but I think this is typically more to it than that. The whole Multicasting thing is new to me. Thanks, Chuck

[kaare_t 155]

So are the axis motion controllers exchanging information between them, or are you simply going to send data from the axis motion controllers to the PLC? Are the PLC going to send commands simoultanously to all the axis motion controllers, or do control them independantly? These are some important aspects when choosing multicasing or unicasting, and the way you describe your system it really seems to me that you should use unicasting. I'm sorry to bother you with this, I know I'm not actually answering your question(s). Edit: BTW, I've looked through the manual and it seems that you should be able to set up a multicast address in the FX3U-ENET. The manual states that any address between 1.1.1.1 - 254.254.254.254 are valid addresses so it looks like it should work. The manual also states that the router must be an A, B or C address, so I doubt that they have "forgot" to mention this for the general addressing section, in other words it looks like you should be able to use a multicast address.<BR><BR>I will not guarantee it and you should definetively test it on your own, but it looks like it should work.<BR><BR>I'm still interested in my initial question so if you have the time, please answer my questions above. I would really like to know why you have this "special demand" and for what reason you think that you need to use multicast for..... Edited 16 Nov 2010 by kaare_t

[cadomanis 0]

As is so often the case I find with Mitsubishi manuals, only one of the 2 sections you found seem to be accurate. When I set the PLC to send to a Multicast address ( 224.0.0.1 and 239.0.0.1) in both cases it always throws a C015 error - which seems to be invlaid IP address and states taht the IP address must be A/B/C. So it looks like Multicasting is a non stater with the FX3U. As with an number of other things about this module, I do not understand the point of making something that is so open, and yet has these odd limitations like port number restrictions ( how I would love to have port 502 available to write a legitimate Modbus function) and ip address restrictions. If there is anyone who understands these reasons I would love to know. With respect to the question why Multicast - well the idea was that both internal to our system as well as with other systems we interconnect with, there was a real desire to have status information of a given axis readily available and not have to always poll for it. By multicasting, the ends points could decide if they wanted to listen or not. For our smaller systems I will likely just revert to broadcasting. This becomes harder when we are interfacing with other show systems as they often do not like the broadcast traffic. Also, given the limitation of the 8 connections to the FX3U, I didn't want to have to burn connections for TCP connections to other listeners, and constantly switching IP addresses on a single UDP connection seemed silly given that is what Multicst is for. I probably go to some form of the last idea where I will have to configure and store a set of listeners and then cycle through them. Not very efficient. thanks, Chuck

[kaare_t 155]

I do agree with you on the limitations of the Ethernet module(s) (it's the same with QJ71E71-100 and restrictions). Luckily there is a QJ71MT91 card for ModbusTCP on the Q, but we're missing ModbusTCP on the FX-Series. Allthough if you have the possibility to use a different port than 502 I know there exists function blocks for GX IEC Developer or GX Works 2 which implements the ModbusTCP protocol for the FX3U-ENET (but as mentioned you'll have to use a port above 1024 which is the limitation of the ENET module). Regarding Multicasting I know understand why you want to use it, and I agree with you that this would be the most efficient way of doing it, however I have a suggestion of a possible solution to the problem: You define a UDP listening port in the FX3U-ENET, which listens to all IP addresses (set 255.255.255.255 in the Incoming connections). Then, in your controllers you simply define which IP addresses they should send data to (and then include the FX3U-ENET). When all your controllers send data to the FX3U-ENET module you can distinguish them by the incoming IP address (or a byte/word you use in your specific protocol) to know where you got the data from. By doing it this way, you don't burn up the FX3U-ENET ports (you can have one port for all incoming data), and you don't have to poll data from the controllers. Let me know if my English was non-understandable or if you have any questions....

[cadomanis 0]

I have used both modules on the Q platform and agree with you completely. My bigger frustration is how expensive all these modules are which then have odd limitation. Do you happen to know a source for the FX Modbus function blocks? I am likely headed down that path on odd port numbers, but would love not to have to do ti all from scratch. I have found a presentation about the FBs, but not the actual code. I like you idea for the listening to all addresses on the FXs. I think I was headed that way as well. The drag is you still need to do some kind of polling routine in each sender to send to the different addresses which sadly means the other axes get the data updates at different times. I need to think through it some more and see what can be done. thanks, Chuck