Damian

This is one of the reasons I think the software should install alaways in a "versioned" folder instead of always having the most recent as "VisiLogic_C". Make is so that you don't have to uninstall other versions just to re-install more. Make "Version Swapper" obsolete.

Hi Bill, I have used the Modbus routine you speak of for the compact logix and a serial connection. In fact I used it to communicate to a V570 and it has worked really well. I will never understand why they don't make a real fucntion block out of it and be done with it. I have often wondered why someone couldn't make it work for Modbus/TCP using almost all the same code. It looks like it is mostly the lack of ability to handle "socket" connections. It irks me to no end that my L35E and the V570 are both connected by etherenet to the same switch and I still needed a serial cable between the two to achieve communication. Hopefully someone sufficiently clever and endowed with lots of free time will figure it out some day. Damian

My situation was this. I had installed Version 9.0.0. to mess around with on my new PC. Then I decided to install 8.6.3. for the actual work I had to do. To do this I had to Uninstall 9.0.0. first (or at least i chose to do this way for fear of some kind of conflict with 8.6.3). Just about every other software package I use installs the software in a directory with nomenclature to designate the version. I can't think of any "advantage" not to do it that way.

Try running in XP Mode.

Hi Bill, Can you please explain what you meant by "The Logix5000 series support it in code"? Thanks, Damian

If you are losing your socket connection it could be either an issue with your ethernet switch or simply a bad connection.

New request. I believe this one to be very simple. When Visilogic is installed on the PC, why can't the latest version still name the directory that it is installed in based on the current version? Or more simply, instead of just "Unitronics VisiLogic_C" why not "Unitronics VisiLogic_C_V8_6_3" ?

Simon has a good point. Makes little sense to have 16bit color if the HMI objects can't support them. Should be able to pick from a color pallet and save that RGB code as a favorite. The 3d buttons would really benefit from having more than 9 colors.

Stumbled across this today... http://www.designworldonline.com/articles/6661/21/Miniaturized-Positioning-Controller.aspx Miniature motion controllers based on CAN. Possibly something Unitronics can Re-label or integrate into their architecture to expand their motion capability.

Why would they make it exclusive to the V230/250? There are Siemens HMI's in the area that I could replace with a V570 if they had profibus.

.................................... Crickets ..................

Hi Ash, Thanks for the tip. I'll definitely take you up on your advise. Does that mean also that I don't need to worry about running it in XP mode? Thanks, Damian

Hello All, I have ordered a new Laptop and have finally worked up enough bravery to step out of my windows XP pro comfort zone. The new PC will have Windows 7 Ultimate 64bit. It also has a so called XP mode that supposedly allows you to run programs as if your machine was a 32 bit XP animal. I was hoping to hear success stories from other's that have the same OS and running Visilogic without issues. Is everyone already running on the platform without issue, or should I brace myself for heartache and agravation?

Hi Darwin, I've been to Honduras. Nice people. You will find in the support section of Uni's main site a document that was written that discusses using DF1 to communicate to an Allen Bradley PLC. Depending on what you have, my recommendations would change. In my instance with the Compact Logix, I actually used Modbus RTU instead. This is also possible with a Micrologix. You can also do this with a SLC CPU but only with the most recent firmware and software. If you choose the DF1 route, I only had luck with passing 16bit integers. Everything else gave me difficulty. It could have been just me, but Unitronics themselves don't have much internal support for communicating with AB so those of us who try are primarily on our own. Warning, Using DF1 needs to be approached with caution. You definitely want to work things out on a table first before putting on a machine. The memory mapping can get confusing and if you mess is up you can easily overwrite areas that you should not be. Once you get past the addressing the code itself is very simple. Damian

Post your code

I'm still confused. Why can't you setup all the pumps to be modbus slaves to the V570? Does the "master" pump necessarily have to be the Modbus master?? Also, if you have a V130 in your system talking CAN with the V570, doesn't that have the additional comm ports your looking for? What's really in control here? The Unitronics or the Pumps?

Emil, Cara, or anyone in R&D, One of my biggest hurdles with the Unitronics product in general is Ethernet connectivity. For control architecture, we are pretty much limited to Modbus TCP/IP. On top of this limitation, we are then only allowed 4 concurrent socket connections. Since I commonly do projects with many nodes of ethernet this makes Unitronics unsuited for projects that in all other facets it would have been more than capable of. I have been lobbying for the adoption of either the addtion of more sockets, or EthernetIP for some time now. Either one of these solutions would effectively overcome the issue. Last year about this time I did quite a bit of experimenation with "socket sharing". Basically instead of dedicating a socket to one device the socket would be opened and closed to sequentially establish connections to many devices. What this experimentation showed was that it takes an eternity for the V570 to establish a socket connection in comparison to how long it takes to actually transmit data once the connection has been established. In "real" numbers I found that with no artificial time delays added, it took about 100ms for the Uni to establish the connection regardless of what my slave device was. Therefore if I have say 4 devices on one socket, I am looking at close to a half second update rate for data refresh. Completely untenable with machine running at sub second cycle times. Recently, the thought has popped into my head, why does it take so awfully long for the connection to be established? So I did some reading to try and find out what is normal or expected. To my suprise, what I found was there doesn't appear to be a good reason for it taking so long. Some documentation suggested that socket connections could be established at the sub millisecond level. Even if we were up around the milisecond level, that is still plently of time to handle socket sharing in the ladder and achieving acceptable performance. Soooooo ...... I guess what I am doing is requesting the R&D department to look into their TCP/IP code to see if anything could be done to decrease the socket connection times. My suspicion is there are a series of conservative time delays built in to account for connecting to "slower" devices. Maybe they are parameters that could be made variable or part of the Modbus IP Cofig block so that we can refine the values to better suit our individual needs. Or possibly there are just delays that simply don't need to be there at all and since the code works noone has bothered to question it. At least in my case, it would go along way towards helping me use Unitronics on more projects. Thanks, Damian

On the later, when done in the hardare setup, you can generate a pulse without really having anything in the program. No function blocks necessary. Easiest way of converting PWM to analog is in the software. Provided you have an available hardware analog output. If you are trying to make a cheap and dirty analog output using a digital output, there are many pitfalls. It would kind of work provided you required very crude accuracy and the input inpedence of what you were feeding is very high, and the resistor used was sized large enough to keep the instantaneous current well within the range of the output transistor. Then you have to consider the "filtering" effects of the RC combination and what that does to the response time between when a change is made to the PWM signal and when that change settles out on the output. Unless you are stranded on a desert island and have no other way, it probably isn't worth it.

Simon, I agree. I think the market for anything above 12" will drop steeply in volume anyhow. Probably not worth the development costs. In those cases, if they really wanted to amp up the sizes, maybe it would be better to re-label an off the shelf touchscreen and interface it to the guts of a V570. The Four biggest reasons I often have difficulty getting Unitronics on a job are: 1) 5.7 inch screen often just not big enough (Soon to be solved with the V1040) 2) Limited fieldbus capability (EthernetIP and Devicenet are huge in my neck of the woods) ASIbus, and Profibus are probably next on the list. The hardware to do both EthernetIP and Devicenet is practically already there (ethernet port and CAN port). 3) Poor brand recognition. (This continues to get better, and addressing the two above items would help that tremendously) 4) Limited to 4 ethernet socket connections (as ridiculus as this sounds, it has killed several projects that ultimately ended up being switched to a CompactLogix) If you need fast ethernet control to more than four ethernet based devices your out of luck. This could easily be overcome by EthernetIP. Ash, I've heard a lot of good things about Ethercat. Unfortunately it just doesn't seem to be as wide spread yet. It will be interesting to see the direction Fieldbus takes over the next decade. Maybe QEB (Quantum Entanglement Bus) or SFBAAD (Spooky Fieldbus at a Distance). Wouldn't wireless be wonderful and frightening all at the same time.

Based on projects I have seen and been on, I think the 10" and possibly a 12" will satisfy the vast majority of demand.

Yeah, and an extra big port to plug in the video game cartridges. Anyone need a "mine sweeper" or "solitaire" app for the V570?

I'm relieved. You had me thinking they were going to be pink and purple with little pigtails coming out the sides. Oh sure Cara, kick me when I'm down!

Hi Vidmas, Ignore all the stuff about Object member. You only care about the address. For the "holding registers" register address 9 is "supply FC frequency setpoint for Stage 1". If you want to read this value in you will use the slave starting address as 9 and the Length as 1 using a "Read Holding Registers (3)" function. If you want to write a new value to this register, you would need to use the "Preset Holding Registers (16)" function instead. The "object member" codes they list seem to be referencing internal memory locations. They should not have any ramifications on the MODBUS mapping. It looks as though Unitronics does not support all of the functions your controller has (such as read only one input register, read only one single state register). Your controller also references the reading and writing of single coil registers. You might have to experiment to see if Unitronics Read Coils and Write Coils function are compatible with this. Hopefully you can accomplish everything you need with just the Holding Registers. Fortunately all your registers appear to be 16bit. This also makes things much easier. You'll be able to load them directly into MI registers one to one. Good Luck!

Ofir is right, a screen shot of the chart would help. Are you reading 16 bit values or 32 bit values? Not sure what your documentation means by "object" in this context. If it is referring to the type of data or the offset of that type of data (ie . bits, floats, ints, etc) then this is already implicit in the function call itself. If your register address is 9 and is 16bit, then really your vector start should only be 9. Do you have a link to an online manual associated with the documentation you have??

It almost sounds like the above is ASCII. It sounds like your using modbus, so you shouldn't have to worry about how the Data is framed. You only need to worry about the address of the data you are looking to poll. Slave Start of Vector is the Modbus address that the data in your slave device maps to. Is your device a Modbus device?