dahnuguy

It will if this is done in a interrupt routine orrrrrrrr you can use the scan time as the base for a "timer" every scan, take the scan time from the system register and add it to a total time. When the total time exceeds the desired time, trigger some event and reset the total. Simple easy scan independent timer. Doesn't matter what your resolution is, unless you use an interrupt, nothing will happen until the ladder scan gets to that point in the logic anyway. INCrement makes a quick and easy ramp too.

What happens when you add a 60 ohm resistor in series with the PLC 190 ohm input? The 0-5 V out should see 250 ohm. 0-5 V through 250 ohms should give you 0-20 mA. This assumes that the output device will drive the current.

Then all you really need is the amount of output required to make the motor run at 60 RPM and then set the output to that amount and leave it. Maybe a stop start added in.

Fabio, Can you give an example of the the "operator panel" you mention? I agree, Modbus in Step7 is not simple or easy and when I did it a couple years ago, the function blocks that come with the module from Siemens did not work. There were also several issues getting the software to work after the correct function blocks were found. If I could avoid that with your suggestion, I would like it much better.

I am aware that I can export and import a subroutine. In previous versions of VL, I was also able to build a generic subroutine and then , without leaving the editor, highlight the subroutine, press cntrl+c and then highlight the module and press cntrl+v. A new subroutine would appear with the same name as the copied subroutine with a "_01" after it. ( or something similar) original_subroutine original_subroutine_01 original_subroutine_02 etc Then I could use the replace function to change the memory in the new subroutine. Since my mouse has 2 buttons mapped to copy and paste this was a two click operation. And it was very quick and useful. I noticed that there was no copy paste in the right click menu when a subroutine is highlighted, but the keyboard keys still worked. Was this changed intentionally for the new version? Is there a way to add this back in?

Works now, I should have caught that.

I added 6300=1 to OPLC.INI, rebooted, etc. No fast open blocks. See attached image for my screen shot.

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. 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.

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.

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.

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.

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?

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?

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?

how about using an addition function to add some amount to itself every scan and then use the result as the input to a scaled block? change the amount added to change the speed of the ramp. If Y is less than Setpoint, Then add X to Y Can also decel with subtract. Could also control around a setpoint...........