Dz!

I know the topic is quite old, but recently I have stumbled upon exactly the same problem - the very latest version of Visilogic has no reference to V350-35-TU24, as well as none of the versions back to 9.31 has. Until I searched the forums the situation looked very confusing. It is kinda surprising, because V350-35-TU24 are still actively sold and used, however no one cared to fix the software. Anyway - thanks Ofir once more, for suggestion that worked.

Thanks Flex727 for very in-depth explanation. But a question was a bit different than your answer. Yes I know the limits of Ethernet, but is there a limitation on the side of CPU power of the PLC? MODBUS is a high level communication protocol, which, I assume, could not be run completely in DMA. Thus it digs into CPU power available for running system processes and user program, which at one point could start lagging due to high communications overhead.

I try to exchange some data between Unistreams using MODBUS. Communication is one-way, only reads, no writes. I have 12 periodic INT32 reads (at rate of 500ms) set up + 124 periodic single bit reads (at rate of 250ms). At bit 114 it fails with status 2. All other bit reads finish with status 0. Suggested queue length reads 16. No extension. I'm reading 2 slaves of the same type an software version, and both perform exactly the same. I tried with 3rd party MODBUS scanner software, and there is no problem reading the address. EDIT: I found the answer as well. The very final bit (bit 123) was not defined on the slave. Thus it was simple 'read past end of data', and by saying status 2, at some place not far from the end, it simply informs that last byte of packed bit data could not be correctly read. That's a good lesson learnt working with bit data on MODBUS. However the question still stands - is there any practical limit (in terms of available processing time), how many bytes could be exchanged using MODBUS TCP?

There is a bug (i assume that is not 'by design' due to some unknown reason) in Modbus master config. While it is said (in help), you can individually disable Periodic Registers, by putting their respective Active bits low, you cannot do it by putting General.OFF bit constant directly into config. Instead you have to make bit variable, assign General.OFF to it, and then put that variable into config. That way it is finally accepted.

I wrote already in initial post, that's not an option this time - a) because of enormous job already done; b) because there is no guarantee that any of the static elements will not be requested to be converted to dynamic element at any time. But our dear moderator decided he could cut every possible detail, leaving almost entire post meaningless. Anyway, the suggestion to rise direct support request was fantastic. I get my problem solved within hour.

Recently working on project, I ran into limit of 256 display elements. Is there a way to extend number of display elements?

By the way, there is still a bug somewhere deep inside. The SMS communications still hangs from time to time, and then the only solution is to completely reset power to the panel. I'm using Cinterion BGS2T modems and initially the communication were hanging very often. Then I found it might be due to the fact that other language messages are allowed only 1/2 of length of the English language messages. I truncated everything as much as I could, making sure the maximum length was not exceeded. Frequent hangs went away. However there still remains some instability in form of hanging SMS comms once every 2 weeks to 3-4 months, with no other way to solve than to restart everything completely (resetting power to the modem doen't help, reinitializing comms doesn't help also). I guess, there is something wrong with the comms buffer within PLC, but this is just a wild guess...

It's rather small modification but could potentially relieve from a ton of unnecessary annoying work. Let's assume you have made UDFB which requires arguments, for later reuse gazillion times in your project. But not every time you use that UDFB, all of the input and output arguments are required. It would be nice that at least output arguments could be omitted when not necessary calling such a function. I guess that's not so hard to automatically pipe them to NULL by compiler, instead pushing us to cork every unused output with some dummy tag. Almost the same is true for inputs - assume, zero length string, zero, FALSE, for everything that's defined, but not explicitly used as input.

Thumbs up! Parametric drawing was a long awaited feature!

...or set up Modbus slave on your device for your SCADA to have place to connect to.

Full 10 point vote for implementation of this functionality from me as well! In Bradley's RSLogix that's as easy as 123. Here you cannot even open two projects at the same time...

Bump, to the topic almost two years old. The 5-th is not even near gone. I need those functions even more than before. To refresh those needs exactly - a) kind of XY plot which is not drawing any curve at all, but rather referencing point at Y-axis to one at X-axis. (See upper picture); b) heating function implementation in ladder function block because it involves quadratic (that means floating point operations) dependencies with some rather complex compensation values, or linear interpolation function with multiple break points (preferably changeable). (See lower picture)

I agree so much to you, 'hotwires'! Having everything pre-planned is one thing, having to modify the project from one (mostly similar) site to another "just by little" is another story. Currently I'm that far from original now, that I was forced to write entire HAL (hardware abstraction layer) to separate ever changing IO from base functionality. I hope, at least some will understand what that means to Alarms base. And, yes - having the Alarm system that sends e-mails or SMSs is another pain in the ... . I have currently written SMS system that has every alarm (>100) duplicated to it in all three languages (user configurable per recipient) with user configurable recipients base of up to 5 numbers.... "It's not that it's difficult, just time consuming". Thus having single place for configuring alarms both for on-screen display and distribution (via SMS & e-mail) would again improve productivity.

Nice to know the reason behind it - so let's do it the way it was designed - external edit (in Excel for example) and group (range) paste, no problem for me. Yes, I know. But it is a lot slower than simply duplicate. Actually, I assume, nothing should be checked by the internal logic at this simple yet powerful step (I mean duplication), because there is no reason to have two exactly similar functions - the duplicate function will be modified by user to some degree anyway (in turn eliminating anything that should not have exact duplicates).