dahnuguy Posted July 13, 2012 Report Share Posted July 13, 2012 I want to use one of these: http://www.beckhoff.com/english.asp?ethercat/ek9000.htm or if this one will not work, then some other Beckoff product to communicate over ethernet to the Beckoff I/O. Has anyone done this? Should it work with the usual Ethernet blocks in Visilogic? Quote Link to comment Share on other sites More sharing options...
Damian Posted July 13, 2012 Report Share Posted July 13, 2012 It should be fine using Modbus TCP/IP. I assume you are deliberately avoiding a CAN connection. Keep in mind that some of the specialty modules for Beckhoff will not be compatible with a Bus coupler. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 13, 2012 Author Report Share Posted July 13, 2012 yes I am avoiding can I have used Can and Modbus with a V350 and in the same project even. MB is just easier to use and more robust. But I had trouble with the MB too. I wanted to use all 4 sockets to communicate with a bunch of other PLCs and I could never get all 4 sockets to work. Other than that limitation, MB worked great. Can was problematic. And I did not realize at the time that the analog outputs are not updated every scan. There was a lot of things I found that were not mentioned anywhere. It looks like the recent versions have improved documentation though. As for compatibility, I have not seen any modules that stated they were not compatible with a Bus Coupler. I like the Beckoff quality and compact size and reasonable price. I will be using D I/O and some analog and I liek the high current outputs. Nothing very special about anything I am doing. If these modules you refer to can't be used with a bus coupler, how are they used as remote I/O? Quote Link to comment Share on other sites More sharing options...
Damian Posted July 13, 2012 Report Share Posted July 13, 2012 You'll get no argument with me . I am not fond of CAN. If you consider the low cost (cabling, switches, connectors, electronics, etc) , speed, robustness, and interchangability of Ethernet I don't see why anyone would use CAN in a new implementation unless they have just such a huge installed base that it is the only thing that makes sense. I would like to see Unitronics make an Ethernet version of the A2 for the remote I/O. In fact I often wish they partnered with a company like Beckhoff or Wago on their I/O and just focused soley on the HMI/PLC. Would love a Unitronics that you could actually snap in Beckhoff modules. You could probably get about a dozen of them across the rear of a V570. I never had any issues getting all 4 sockets to communicate simultaneously, but I do admit to spending quite a lot of time on the communication routines to make sure they were optimized for speed and robustness. Biggest issue I ran into was when I needed to share a socket the Open/Close times were too long. They made me a FAST socket Open/Close block (look at the new Immediate Open and Close blocks) that allowed me to overcome that. Up until then what I would have to do is make an "electronic distributor cap" of the sockets such that it would rotate through 2 or 3 of them and start connecting to the next one while I was reading the current one. That was a lot of ugly indirectly addressed code! I had the new Beckhoff servo terminals quoted a couple weeks ago. http://www.beckhoff....9000_bk9050.htm The rep told me that I would not be able to use these with the Bus coupler and that there were other modules like this that also were not capable of it. They quoted a CX5020 instead with an EthernetIP slave driver. I have requested a compatibility chart from them, If I get it I will share with you. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 13, 2012 Author Report Share Posted July 13, 2012 I agree 100% with your assessment of the Can versus Ethernet issue. My trouble with the sockets may have been related to the delays as well. I tried everything I could think of and every suggestion, but only one socket would work at a time. It is so difficult to know what is happening with with the coms and different functions. I appreciate your feedback. A compatibility list would be nice, thanks for the offer. I am confused by the link you sent, that IS a bus coupler. Are you saying that this compact bus coupler is not compatible with the Unitronics Ethernet? Quote Link to comment Share on other sites More sharing options...
Damian Posted July 13, 2012 Report Share Posted July 13, 2012 Well that is strange. Beckhoff's website is flakey. The inner page and the outer page act separate to each other. I had copied the link out of the address bar with the servo module showing, but the address bar did was still on the Bus-coupler page. Anyhow, i was talking about the EL7201 http://www.beckhoff.com/english.asp?press/pr4510.htm Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 13, 2012 Author Report Share Posted July 13, 2012 ah ok, so the servo module can't live on a bus coupler eh? Probably to much lag or different data structure. I liked those modules and was thinking of using them on a remote I/O drop. I guess I will have to do something else or step up to a different controller for that. Quote Link to comment Share on other sites More sharing options...
MVP 2023 Joe Tauser Posted July 16, 2012 MVP 2023 Report Share Posted July 16, 2012 They made me a FAST socket Open/Close block (look at the new Immediate Open and Close blocks) How did you get your paws on these? Joe T. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 16, 2012 Author Report Share Posted July 16, 2012 Biggest issue I ran into was when I needed to share a socket the Open/Close times were too long. They made me a FAST socket Open/Close block (look at the new Immediate Open and Close blocks) that allowed me to overcome that. Up until then what I would have to do is make an "electronic distributor cap" of the sockets such that it would rotate through 2 or 3 of them and start connecting to the next one while I was reading the current one. Open and close times were too long eh? I was under the impression that these instructions were done in a scan. I am not surprised to learn otherwise. I have looked and I do not see these Fast open and close blocks you reference. I am very interested in these for an upcoming project. Are you saying that the open and close socket instructions have been changed and are now faster / better and are the standard functions in the new software? I looked in the "new Immediate blocks" under "Utils / Immediate" I don't see anything there about ethernet sockets. I don't see anything under "Coms" or "FBs" either. Or are you referring to a subroutine that someone at Unitronics wrote for you? Would be too much to ask for you to post a striped down program that includes your open close sockets? Maybe a subroutine of your fast coms? I went through this same exercise a couple years ago and spent a lot of time on the coms. I could never get it to work the way I wanted it to no matter what I did. Thanks for the information. Quote Link to comment Share on other sites More sharing options...
Cara Bereck Levy Posted July 16, 2012 Report Share Posted July 16, 2012 (edited) Guys--hang on a little bit, please. How did you get your paws on these? Joe T. He asked me Seriously, Damian wrote to us regarding a specific problem, and we developed specific functions. We did not release them with a version because they have not been fully tested by us, although Damian has--apparently--been using them. I am waiting for one of the OS cowboys to peek into the code and tell me if these functions are supported with the most recent OS, or if you have to use the specific OS that was released with those functions. (I checked: yes, the current OS does support them) As far as revealing them in VisiLogic: Disclaimer: Please note that these functions have not been fully tested, and that Unitronics bears no responsibility for their use. Simply open the OPLC.ini file, then add a row: 6300=1 That should do it. You will see the Fast Connect functions under Com>TCP/IP, under the Close: TCP function. Note: ‘Connect Within’ is a timeout value: the program scan stops until either: -the connection is made (and if it is made in 1 MICRO-Second, the scan will continue after 1 micro-Second) Or -the ‘Connect Within’ time has elapsed. You’ll want to monitor the relevant socket SB, of course. I'm afraid that is the extent of the information I have. Edited July 16, 2012 by Cara Quote Link to comment Share on other sites More sharing options...
Damian Posted July 16, 2012 Report Share Posted July 16, 2012 We did not release them with a version because they have not been fully tested by us, although Damian has--apparently--been using them. . Doh! ................ Sorry. I don't remember having had to do anything special to get them to show up last time, so I assumed they had been officially released. My appologies. Regarding the OS compatibily, I am not certain to be honest. I went a while sticking with an older version of Visilogic so It may not work for all I know. Quote Link to comment Share on other sites More sharing options...
Damian Posted July 16, 2012 Report Share Posted July 16, 2012 Open and close times were too long eh? I was under the impression that these instructions were done in a scan. I am not surprised to learn otherwise. I have looked and I do not see these Fast open and close blocks you reference. I am very interested in these for an upcoming project. Are you saying that the open and close socket instructions have been changed and are now faster / better and are the standard functions in the new software? I looked in the "new Immediate blocks" under "Utils / Immediate" I don't see anything there about ethernet sockets. I don't see anything under "Coms" or "FBs" either. Or are you referring to a subroutine that someone at Unitronics wrote for you? Would be too much to ask for you to post a striped down program that includes your open close sockets? Maybe a subroutine of your fast coms? I went through this same exercise a couple years ago and spent a lot of time on the coms. I could never get it to work the way I wanted it to no matter what I did. Thanks for the information. Well it can't be "done" in one scan. At least not reliably. Mostly because to complete a connection requires some time, and also depends on the one being connected to. I was complaining that it was difficult to share a socket on the Vision product and that I knew it wasn't a result of the slaves I was talking to because I used something else to talk to them and it was an order of magnitude faster. So the delays were in the Uni. The new FBs are much faster and makes sharing a socket much more viable. Especially with the 4 socket limitation. I appologize, but I had wrongly assumed this was released. So I would not recommend using it unless you are willing to be a Guinea Pig for it and possibly limit yourself to a specific OS and Visi release. They may not be "better". It establishes a connection faster, but I am sure to get something you usually have to give something else up somewhere else. I will make you a stripped down version of my socket routine. There is nothing novel going on in any of them, but it has been out in the wild now for a few years on several machines and has proved robust. Quote Link to comment Share on other sites More sharing options...
Cara Bereck Levy Posted July 16, 2012 Report Share Posted July 16, 2012 OK, I've got the answer--the current OS supports Fast Connect/Close, and adding the line to the ini file will expose the functions in the current VisiLogic version. I would be very interested in hearing if the functions are helpful in your application. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 17, 2012 Author Report Share Posted July 17, 2012 Thank you, everyone. I am still reeling from the statement about "he just asked and we made it for him" Wow. That's nice. In my previous project I could never get more than one socket to work, so I was limited to the number of stations I could have. And since they all had to use the same socket, it slowed down the communication time as I was sending and receiving data from 30 other PLCs. I wanted to break it up and fewer PLCs on each socket. That was back in version 7 or 8 though. I am excited to see how the new version has been improved and I am looking forward to using the new com blocks. Thanks again. Quote Link to comment Share on other sites More sharing options...
Damian Posted July 17, 2012 Report Share Posted July 17, 2012 Thank you, everyone. I am still reeling from the statement about "he just asked and we made it for him" Wow. That's nice. In my previous project I could never get more than one socket to work, so I was limited to the number of stations I could have. And since they all had to use the same socket, it slowed down the communication time as I was sending and receiving data from 30 other PLCs. I wanted to break it up and fewer PLCs on each socket. That was back in version 7 or 8 though. I am excited to see how the new version has been improved and I am looking forward to using the new com blocks. Thanks again. Cara left out all the whining, complaining , and groveling I did. I originally simply asked that R&D check into why the connection times were taking so long and see if it was just a matter of some time delays being set too conservatively. I was given the impression that it ended up being more time consuming than was originally anticipated. I never expected the development of new FBs. Even prior to that though, I never had any issues with having all sockets connected simultaneously. I originally developed my messaging routine back in version 7. Greater than 80% of my application involve ethernet. My problem was more so that once you had more than 4 nodes, 1 or more sockets had to be shared. Then my sampling rate on the shared socket would go from a blazing fast read & write cycle of 12.5ms to an abysmal 150ms per device on the shared socket. The fast Connect block allowed me to open, read, write, close, and then connect to the next device in less than 30ms per device. Still not blazing fast, but it did make certain applications more feasible that I would have otherwise has to use a high end controller for. I am curious as to why you had so much difficulty. I suspect you didn't have something quite right in the config. Quote Link to comment Share on other sites More sharing options...
Cara Bereck Levy Posted July 18, 2012 Report Share Posted July 18, 2012 Cara left out all the whining, complaining , and groveling I did. That is because it was spectacular-- I am saving it all for my upcoming soap opera "A Technical Life"... I originally simply asked that R&D check into why the connection times were taking so long and see if it was just a matter of some time delays being set too conservatively. I was given the impression that it ended up being more time consuming than was originally anticipated. I never expected the development of new FBs. Yes--I was joking with the 'he asked' bit. The truth is that while we were checking, it seemed that there was an easy way to overcome the issue with FBs...but, as often happens, it turned out to be more complicated than we thought. Still, we (meaning the R&D team) learned from the process, so we did benefit from it--and Damian got new FBs Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 18, 2012 Author Report Share Posted July 18, 2012 Cara left out all the whining, complaining , and groveling I did. I originally simply asked that R&D check into why the connection times were taking so long and see if it was just a matter of some time delays being set too conservatively. I was given the impression that it ended up being more time consuming than was originally anticipated. I never expected the development of new FBs. I suspected that something could have been made faster also due to not having delays in other devices on Ethernet. I also had to switch socket 0 but for me it was only because I couldn't get the other sockets to work. The fast Connect block allowed me to open, read, write, close, and then connect to the next device in less than 30ms per device. Still not blazing fast, but it did make certain applications more feasible that I would have otherwise has to use a high end controller for. I am curious as to why you had so much difficulty. I suspect you didn't have something quite right in the config. 30 msec isn't what I expected, but it is better than 150 msec. My scan time on that project was around 10 to 15 msec , lower than a previous project, but still could have been an issue, so I stripped it all down to just the coms and tried to work it out. But still had the same issues. I did notice that the coms got worse as I added the code back in. So maybe it was affected by the rest of the code. Either way, it still didn't work right with only the coms. I had all 4 sockets set up the same way, but using different variable as one would expect. I don't have access to all the equipment anymore, so I don't have anything to around to recreate the same issues. Any code I have left over from back them , may not be the actual version I used. I will look in my archives and see if I can find a version of my 4 socket trials. I don't typically keep code that doesn't work though. I wish I had time and resources to sort through issues and solve the problems, but I rarely have the luxury. If only I had a simulator that would connect twelve V350s, all running different code , all at once on my PC...........as virtual PLCs......... Ok that is unrealistic. I will settle for a sim that lets me run code on one virtual PLC. Quote Link to comment Share on other sites More sharing options...
Cara Bereck Levy Posted July 19, 2012 Report Share Posted July 19, 2012 If only I had a simulator that would connect twelve V350s, all running different code , all at once on my PC...........as virtual PLCs......... Ok that is unrealistic. I will settle for a sim that lets me run code on one virtual PLC. I know...it is high on the wish list, and something that I hope we will one day be able to offer. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 19, 2012 Author Report Share Posted July 19, 2012 As far as revealing them in VisiLogic: Disclaimer: Please note that these functions have not been fully tested, and that Unitronics bears no responsibility for their use. Simply open the OPLC.ini file, then add a row: 6300=1 That should do it. You will see the Fast Connect functions under Com>TCP/IP, under the Close: TCP function. I added 6300=1 to OPLC.INI, rebooted, etc. No fast open blocks. See attached image for my screen shot. Quote Link to comment Share on other sites More sharing options...
Damian Posted July 19, 2012 Report Share Posted July 19, 2012 You have to add the 6300=1 under the [6000] header int he OPLC.ini files. Quote Link to comment Share on other sites More sharing options...
dahnuguy Posted July 19, 2012 Author Report Share Posted July 19, 2012 Works now, I should have caught that. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.