cadomanis

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

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

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

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.

The panel calls it "Remote Access". In truth it works exactly like the VNC protocol and you can in fact use any VNC viewer instead of just the one provided by Beijers / Mits. see www.realvnc.com for more info. Yes, I have been successful at using the mobile broadband device at teh E1101 end. I am currently facing the same chalenge as you in that I can;t get access to the locations network. Here in the states I have been able to get a mobile braodband PCMCIA card and a Linksys router taht will accept it as its WAN connection. then by setting up port forwarding and dynamicDNS in the router, I am always able to gat conencted back to the remote E1101 ( and the connected PLCs as well). I know there are other makers of that hardware out there are well. My conenction needs are very intermittent, so I waswilling to go with more comsumer level gear. If you really need to get connected all of the time, I know that DIGI makes some more robust units with a lot more connection options. Hope this helps. If you get into it, I can help you with router / port forwarding setups that have been successful. Chuck

I have had good success with remote accessing the E1101 panels. Typically I have used the VNC like remote conenction. Using the full control option, you can navigate around the HMI as though you were at it and could see anything you could see locally. I am pretty sure you can usea similar connection to access the panels filesystem using FTP which I believe is where the trend data would be stored. The really nice feature I have found on those panels is that since you can select the port numbers for all of the various functions, it is very easy to put them behind a router and set up port forwarding to access the various functions. In my applications we are usually on a dynamically assigned connection so I use a router with the dynamic dns function to be able to always get back to the devices without knowing the actual IP address. You can get back to teh router using a domain name, get the current dynamic address and then use you know port numbers to access the functions of the terminal. I have even done this successfully using a mobile braodband router to do updates to devices at remote sites. Good Luck. Chuck

I would look at the units from Watchguard. We have had great success using them as an access point to a variety of systems. Q series, HMI, FX plcs all have sucessfully been accessed behiund these units. If you are dealing with multiple locations, they also have some really nice internetworing VPN features. Chuck

Yes. The Beckhoff device is the master. Their devices are highly capable and in this case the BX unit can master CAN, Modbus RTU, as well as conventional 232 and 485 serial while it is also a Modbus TCP slave device.

Anyone ever used the A7NCA CanOpen option for an A/E700 drive. I am trying to get the drive talking to a Beckhoff BX9000 using the CanOpen protocol. Thanks, Chuck

Correct - if you download the demo and all drivers - you will see a Mitsubishi suite. It has a special driver set for serial connections.

Kepware is a OPC Server company. Check out www.kepware.com. They make a mitsubishi suite which includes both serial and ethernet drivers. I have done a lot of OPC with Mitus PLCs and find kepware to be vastly superior to Mitsu MX OPC. In all cases you are going to be talking one of the Mitsu protocols. Be careful about how you stack you data if you need comm to be efficient. Get everything packed together in memory as tight as possible so you can read big blocks at a time. Also, if possible move you bit devices into words - again much more efficient.

Check out the Beckhoff BC9100. Uses their TwinCat software which is essentially the same as CoDeSys. Base is around $300US and you can add what ever IO you need. Has ethernet built in!!

Look carefully at the port numbering you are using. I had this same issue with a 2 PLC setup. You may want to be sure to use different port numbers for the connections. Also, be careful how your different GX developer sessions are setup. those settings are per project, not per developer and so you may have the project for two of your plcs trying to use UDP to comminucate instead of TCP. Chuck

Thanks. This is helpful. Kind of what I figured on the TCP side. Was surprised with all the details in the manual that the don;t mention this. Thanks. C

I have recently deployed several system that use the QJ71MT91 Modbus TCP master to communicate with some Beckhoff BC9100 Modbus bus controllers. when everything is working well, the system has an increduble response time and everything is great. The problems come in when we have something go wrong. Let's say one of the BC9100 slaves gets umplugged. The PLC seems sometimes able to get the unit bck online, and other times not. I did some wireshark capures and see that firs the MT91 resends the modbus request, and then after several tries it sends a RST to the coupler. Finally, after getting no ACK back from the coupler, it starts send out SYN on 10 second intervals. I can make some sense of this from the timeout settings explained in the MT91 manual, but it doesn;t ever talk about the SYN messages. I can find references to RST and FIN messages only. If anyone else has experience with the MT91 modules, I would love some advice. I am sure I need to adjust all of the timeouts from the defualts to make our system more robust in a failure mode, but not sure where these SYN messages are coming from. Thanks, Chuck