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

keep in mind that using the direct cell location will method will not shift the access point if a new column is inserted before the cell being addressed.

share?

I like to see a follow up post on the solution.

conductor resistance is less of an issue with 1000 ohm RTDs as the iwre resistance is small in relation to the whole resistance. However, I would still prefer to use a 3 wire RTD over a 2 wire RTD. In addition, I always used a transmitter on all the RTDs I used, and brought a 4-20mA signal from the transmitter back to the PLC. If the RTD is less than 10 feet away, (mine never were) it's probably never going to be an issue. Until the RTD opens and you get maximum temperature and the process freaks out. Not common, but I had to be ready for everything working with chemicals.

get a bigger PC screen and then lower the resolution you don't have to use 1080X1920 all the time. it will not be as sharp, but it will be bigger.

1) Make a screen which has a variable. Allow the user to enter an integer in the variable of 0-100% 2)Use the variable above as an input to the PWM function to alter the pulses per cycle. You may need to normalize or scale the variable if you want to enter the value in RPMs or M/sec or some units. Then give this scaled value to the PWM function. This is for open loop speed setting. For closed loop speed control, do the same thing, but add in some speed feedback from the actual device or motor. Again some scaling will be required. Enter 250 RPM on the screen. Scale the 250 to equal 0-100% of the motor speed. Use this as your "setpoint" for speed. Bring in the speed feedback signal. Scale this signal so that it is normalized to 0-100% of full speed. I also use a ramp to start most things, so I would begin incrementing my speed control up. So every X seconds, IF the actual speed is less than the setpoint, then add Y to the speed reference going to the PWM. IF the actual speed is greater than the setpoint, then subtract Y from the speed reference going to the PWM. (Yes you need a window there, yes the times are tricky, no the built in PID in version 7 or 8 would NOT do this. The built in PID back then would only go one way for temperature control like a HVAC system where you only have heat or cool active at one time. Maybe this has been changed, if the new PID is bidirectional, then just use the speed setpoint as the input to a PID fucntion.) (This can become a sort of cheap PID if you are careful and tune it. You can have several stages of more or less aggressive acceleration depending on how far from the setpoint you are (P) and each section can be updated more or less frequently (I) and you can have a separate function to limit the amount of change per time period to a maximum value (D) . It is not simple, but not too difficult if you break it down into small steps. If you approach the setpoint slowly and do not have a large change in load, you may not have enough oscillation to require a PID.) When the actual speed from the speed feedback, is equal to the "setpoint" or inside an acceptable band, then stop the increment. If the motor slows down, this will also pick it back up. If the motor speeds up, this will slow it back down. If you want to change the speed, just change the setpoint. Now if you connect some external signal that sets your speed based on some changing process condition it would be even more fun.

The last time had issues with memory in Visilogics was a couple years ago. Visilogics did not clear all memory when loading a new program. The memory is not initialized. Not even a new PLC had the memory initialized. This was very annoying when you try to make a production product. The production line can load the program, but it wont work until the memory is cleared, or the behavior will be erratic. I made a small subroutine that cleared ALL the memory in thee whole PLC. Then everything worked great. If you go online with a new one, you can scan the memory and see some of the memory locations have data.

This is a common practice in Siemens Step7 but is completely UN-necessary in Visilog. The DataTable is defined in the function that accesses it, so every function has the data table for which it is intended explicitly defined within the instruction. In Visilogic, no data table is "open" after the function is done. They are only open during the function. And each function must explicity define which table is being used for that function. In this way several data table functions can be used on the same rung / network. Copy row from Data table 4 , row 3. Or the symbolic equivalent.

MI's are faster and more robust. Datatable functions are not immediate or even guaranteed under all circumstances. Try putting 4 or more data table functions on one ladder and enable them with a positive transition. I have not used version 9 so this may have been addressed. However, The DT is the best way to list several items and then makes it easier to send them all to the PC. I would use one DataTable copy function and make it a FIFO. Then when the table is full, send it all to the PC and clear the table. 2 lines of ladder. If your data is in an array of MIs it is easy to copy the data into the first row of the datatable and then clear the data in the array. Shift the data in the datatable down one row and continue. If there is data in the last row, send the whole table to the PC and clear the datatable.

can is a one way open loop broadcast modbus is a 2 way communication that uses a handshake to confirm that the information was sent adn received and both sides are aware of the result. Can is faster, but you dont know if the message was received, unless you trigger some sort of return message, which would slow it down. Can does have a heartbeat function that confirms the connection is live, if you use it. It is possible to configure a canopen network with only one node and transmit data and receive no error or indication that no other node received the data. This is not possible with modbus. The heartbeat function is the "old style" can, and will slow down the can network. You choice is fast or robust. And you also might want to consider that Unitronics is a bit tricky with canopen communications. The last time I used it (it could be better now) I found that the canopen function is asynchronous to the PLC ladder. The canopen function also contains pointers to data , the actual data is NOT loaded into a com buffer when the function is called. So if the data changes during the scan that you call the canopen function, the data will be corrupted. This led me to stop updating the data during the scan that a canopen function is activated. This is also a time cost. I needed fast and using two can nodes to talk back and forth was remarkably slow after all the limitations were dealt with. The canopen hardware runs independent of the ladder, the data may be sent at any time during the scan.