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

1) When editing IO Inputs or Outputs Alias Names directly (from the table view, without going into window for editing single tag) - cold not put a space symbol between words while writing (later when the whole "Input5AbracadabraOpenSesame" is written, you can, of course go back and put spaces in between words finally getting to the "Input 5 Abracadabra Open Sesame"). Problem is not observed while editing in single tag editor window. This is new mis-behavior, which was not observed some versions earlier. 2) In Data Table view - String literals are center-aligned without any obvious reason, which detracts from readability of large tables. For Number literals it makes sense to have them centered within cells, which more likely adds readability rather than destroys it, but it's a different story for the Strings. 2.1) In the same Data Table view - it is unable to directly edit anything without explicitly going into editor window for each cell with double click... That's so tiresome and time consuming for large tables. Exception is direct Paste, which however helps little, if each cell is slightly different. 3) Alarms - ID's could not be freely changed... I see no obvious reason for not allowing to do that because there are gaps still allowed (by deleting some alarms in the middle) and no automatic reordering of ID's is then happening. Of course it does not change much, but adds to the overall order and clarity of the project. Thus why not allow to change them freely, of course, with checking for duplicates. 3.1) Alarms could not be moved around (between groups for example). Took me few weeks to reorder entire system of 100+ Alarms... 4) Ladder function could not be duplicated, like almost anything other could. 5) The XY Plot is wrong type of thing, or at least I need a different flavor (see attached pictures): a) XY_Beijer is the reference - a single clearly visible point of arbitrary size is drawn for each feed in data sampler; the lines referencing these point(s) to the X and Y axes are drawn (switchable on/off); the background where any arbitrary function could be drawn or at least a clear background where any arbitrary picture could be put into (switched during runtime, not statically linked); b) there is always a cause - see the Weather_compensation; c) and a workaround - see the Comfo_Uni which is far from ideal, but at least works, somehow... Why all of this - I was asked to implement Comfomatic (Weather compensation for central heating) functionality as addition to primary functionality. Typically it is done in special hardware like Danfoss ECL series controllers, however the underlying mathematics is rather simple, so why not.... It worked out - making a usable user interface is a major pain on the Unistream platform.... d) of course in ideal world, I'd be asking the Unitronics team to implement the entire functionality in specialized function block, both for GUI as well as for Ladder, however I understand there are so many uses for these PLCs that implementing separate function block for each of them would lead to the same clutter which was seen in VisiLogic series software and which the Unitronics guys were presumably trying to avoid in Unistream. e) and there is always a workaround of the workaround - or better, I call it suggestion 2: The the simple Canvas control could be added to the GUI section - thus allowing users to draw whatever they need to solve such challenging tasks... (or if the screen is already a canvas itself, then at least allow to draw some primitives - dots, lines & rectangles from the Ladder (yes I know there is a Line element in GUI, but it is static, you can not even put a variable as its X1,Y1 and X2, Y2 points... thus it's unusable). 6) Each MODBUS target has the Modbus Remote Slave structure attached. This structure has very useful variable 'Fail' within it. It could be ideally suitable for checking for communication problems, and throwing Alarm to the user if any. But what's next - user cannot clear the alarm, because there is now way to drop it to the zero (I mean, there is no way to write 0 to this structure). Yes, of course there is again a workaround - copy the contents to another variable and then compare to it, not the 0, But why always a workaround? Why not do the things right the firsthand. 7) I'm still begging for ability to reorder members of the struct, like it's done in SMS Message composition with the List Of Text Variable - simple control to move members up and down. It has no meaning while the project is little and simple, but when it becomes large enough, when various functionality is added to different parts all the time, when structs determine what is written to different tables back and forth, then keeping various recent additions together with their primary counterparts rather than at the end of the struct, could be soooo meaningful. At present its a tremendous and very time consuming job to reorder the structs, by renaming and replacing every single appearance everywhere, when it could so easy be made to happen automatically. Not to mention, that is so easy in plain C, just cut one and paste above each other... Many thanks for the product already that great (light years away from said Vision or Samba), but of course, any improvement would be warmly welcome. P.S. Please double-check the communication with Cinterion BGS2T modem - it tends to drop from time to time (worse with USB-COM, better with UAC-01RS2, but still not ideal) and then it's unrepairable till the next complete reboot of the PLC... (re-initialisation has no effect).

This is typical behavior after update to the latest version with "improved" UAC (v1.21...) It even forced me to update my PLCs to the latest project software via USB flash disk rather than usual Ethernet, because it simply didn't work. Finally I chewed through this. First, you need to disable UAC, then completely remove the old passwords, and finally re-enable UAC and configure it as you wish. And ,voila, everything works as it should. The "the password for Uniapps Administrator bla, bla, bla..." error is gone. What I would like to suggest to the Unitronics team - could you do the old password cleanup step for the users automatically upon they're changing to UAC, or at least warn them they'll be in trouble if they didn't do that before proceeding to UAC world.

Dear fellows, Anybody might be knowing - what type of string and what length is necessary to store IP address for IP Address Edit and IP to String and String to IP elements. Official help file is scarce on that. Additionally, are the IP fields contained within Modbus Remote Slave structs editable or read only (as primarily these get their information from Modbus Ethernet Masters configuration screens)?

Confirmed to be just a single event type of a glitch.

Could it be a wiring problem? Sounds like that... Try to put your transducers on a test wiring as close to the AIs as you can. Another clue is bad/incorrect reference to the system 0V or 24V somewhere in the system. That, not necessarily has to be close to AIs. It could be as far as any voltage fed back in into digital outs. Unistream is quite sensitive on that. Check everything - any voltages should be where they're supposed to be and shouldn't where the they're not. Disconnecting as much as you can from the PLC and then step-by-step putting everything back could be helpful as well.

Recently switched to v1.21.51. Know what - it crashed when opened together with project (I mean - by clicking on project file, and waiting for it to open the UniLogic via Windows file type associations). I have yet to confirm if it is repeated or just a single event. Application as well as the project opens normally if done sequentially - 1st application, then project within it. No BSODs however. That's why I counted it as minor glitch and didn't open a new thread... My box is i5 laptop with Win 7 x64 onto it.

I stumbled upon exactly the same problem the very first moment I begun working with MODBUS on Unistream. I'd rather disagree with the method Ofir proposed. It is nevertheless correct way how to accomplish that, however it is redundant and unnecessarily bulky. There are a lot of MODBUS devices that keep their status information (in form of bit fields) in their holding registers and receives commands the same way - by changing bit values of input registers. Not a single coil is even made available. Thus it would be very conventional way to gather whatever commands are needed via separate bits of the bit array, and wtite them to MODBUS target in single register-wide operation. Exactly the same the opposite way - read holding register directly into bit array of fixed length (8;16;32) and then use the bits for whatever they are meant for. The method Ofir proposed - doubles the amount of data storage necessary (first for storing int, then once again for storing bits), plus the unnecessary ladder elements for conversion. When doing the same thing in C it is done the most simple and conventional way it could be done - you can reference the same chunk of memory in whatever way you may imagine - as bits, as array, as ints, words, chars... I guess the underlying software of UniLogic/Unistream is written in C anyway, thus it could not be very hard to arrange the data within it the same way. So, what I'm asking for is a single change within MODBUS data definition part - please remove restriction to use Bit Array (of fixed length, or even of arbitrary length with automatic padding with leading zeros) as Tag for storage of Register transmission contents.

Hi! I hope someone of you, both Kings of Uni, might be able to help... The long story short - Unitronics worked hard to make protection of some piece of software a nightmare.... 1) System.CPU HW Version. Serial number returns string "Serial number" (wtf?) 2) There are three at least meaningful IDs - CPU, FPGA and Flash, from which I hope, at least one changes from system to system - but to make things harder to accomplish - all are strings as well... (of course, we have function 'String to Num', but as I said Unitronics tried hard to make simple things a nightmare) Typically I would convert them to nums, XOR them one with another, do some other trick, and, voila, have a "magic number" to compare with for each and every system, the software was put on. But not this time. 3) At least one of those IDs (the FPGA) is HEX! Thus the 'String to Num' isn't working on it. 4) Ok, I thought - let's do it the harder way - cut the string into chars (strings of lenght 1) with 'Middle of String' function (which fortunately works) and then compare them one by one with the 'hex space" ('123456789ABCDEF') which should hopefully return it's position within string, which is exactly the decimal representation of the Hex, by coincidence. BUT... The 'Find Substring' is a "do it yourself" function, because in addition to, of course, requires parameters 'Source string' and 'Find substring' it also requires 'Index in source' (which I assume, works like - Ok give me the string, give me what to find, AND GIVE ME POSITION WHRE IT SHOULD BE, and THEN I WILL TELL YOU IF IT'S THERE).... That's not exactly a 'find', that's do-it-yourself.... Or at least I have got something wrong. But I never got any meaningful result back from the 'Find Substring' function, except 255 (which, I guess, means 'not found'). Anyway, Unitronics lack ANY information on Strings.... So, I'm stuck... I could not get "serial number" because it isn't there; I could not do math on hardware IDs, because these are strings; I could not even convert them to numbers, because these are HEX, and there is no function to convert 'String containing HEX to Num'; I could not make function to convert Hex to num, because 'Find substring' is made for nothing (or at least I hadn't found a way to make it work, and there is no help describing how exactly it works). HEEEELP!