Ash Neilson

Emil - Thought I would post something on this too. I find with all versions of UniOPC Server that you need to click the "STOP" Button before UniOPC can be Closed. If I remember correctly, the reason for it was to prevent people from exiting UniOPC while it was running.

Hi Again. You can use a Vector Fill (Under the Vector Menu). A (Fill Value) = SB0 B (Fill Vector: Start Address) = MB1 C (Number of Operands to Fill) = 100 We use SB0 as the value of SB0 is always False (Reset). This Utility will fill MB1 to MB100 with the value '0' - meaning they will all be Reset. Remember if you just want to do this on startup, put a SB2 contact before it --|SB2|--

Hey! So you want to set MB4 to 1 if MB1 and MB2 and MB3 are 1, otherwise MB4 always is 0? <Net #1> MB1 MB2 MB3 MB4 --| |--| |--| |--() Very simple! If one of the MB's is 0, then MB4 will become 0 automatically. With the Power Up Options - the whole point of it is to RESET an MB when the PLC is restarted or Powered On/Off. If you are trying to keep, for example MB5 reset (0) all the time, just put this in a Net: MB5 --(/)-- Hope that helps you!

Hi John, There is a nice little Ladder Utility that will give you exactly what you want. In VisiLogic 8.6.0 or older, the Utility is under the "Clock" drop down menu, then "UTC", then "RTC to UTC". In VisiLogic 8.6.1, follow the same steps, but it will be under the "Utils" drop down menu. To use this Utility, the Operand that you specify on the input side is actually the "Start of a Vector" Address. For your requirements, putting SI30 into that Utility will allow it to grab SI30, SI31, SI32 and SI33. The Output of this Utility is best assigned to a DW Operand.

Simon, I think Phil is the only one who can delete the duplicate comment As far as the Loop side of things goes. In my experience of using them, I found they would simple "Add the Scan" if you were "Jumping Back" to a Label. If you make a Loop take too long to complete, you can trigger a "Software Watchdog" error, which means the PLC Scan never actually finished within a reasonable time. I just made a quick test program and added an INC Utility in Net 1, made a Label with another INC Utility in Net 2, then in Net 3 a "Jump to Label" so it would jump "Back to Net 2". I also added a INC Utility in Net 4. When I started the PLC Program, the INC in Net 1 counted up just once, then the MI on the INC Utility in Net 2 was counting up very fast - then I hit a Watchdog Timeout because my loop "Never Ended". So based on this one thing to remember would be Inputs and Outputs won't be updated whilst in a "Loop" of Label Jumping. Very handy, but dangerous feature at the same time!

Geert, Chances are you have a "DOS" Screen in front of you at the moment. Press and Hold the Touch Screen for about 4 - 5 seconds. You will then be presented with Two Buttons, tap the "Info" Button. Enter the Password "1111" from there and follow Phil's Instructions

Hi Mate, I assume you are referring to the PComB Communication Protocol, which uses the Binary based data. You actually need to have two Checksums! The first checksum is the last 2 bytes of the PComB Header (Which itself is 24 bytes long including the checksum). The Second checksum is located in the Footer and is the checksum of the Details. Here Below I have broken up the PComB Message to show you where the Checksums sit and what they are a Checksum of: Header: ======== 0 = / 1 = _ 2 = O 3 = P Bytes 0 to 5 are the STX ("/_OPLC") 4 = L 5 = C 6 = <Unit ID of PLC> 7 = 254 (Always 254) 8 = 1 (Always 1) 9 = <Message Key> (You probably won't need to use this, so leave it as 0) 10 = 0 11 = 0 12 = <Command Code> 13 = <Sub Command Code> (Again probably not required by you so leave as 0) 14 = - 15 = | 16 = | Bytes 14 to 19 are usually the 4 bytes of the Address and 2 bytes of the Elements Count 17 = | These can sometimes be "Command Details" relating to the PComB Command Code 18 = | 19 = - 20 = LSB of Detail Length | Bytes 20 to 21 are the Length of the Bytes in the Detail Section 21 = MSB of Detail Length | 22 = LSB of Checksum | Bytes 22 to 23 are the Checksum of this Header 23 = MSB of Checksum | The Checksum of the Header that sits in Bytes 22 and 23, is calculated using all the Bytes of the Header (From Byte 0 to Byte 21). Details: ======== This section of the PComB Message will contain byte data specific to the Command. Refer to the Unitronics PCOM Protocol PDF for information on the Details Section. Footer: ======== This section contains just three Bytes. Two Bytes are the Checksum of the Details Section, and the last Byte is the ETX. 0 = LSB of Details Checksum 1 = MSB of Details Checksum 2 = \ Byte 2 is the ETX ("\") When calculating the Details Checksum, make sure you are using EVERY SINGLE Byte in the Details Section. The Header Section must not be included in the Details Checksum. Both the Header Checksum and Details Checksum are calculated using a Two' Complement calculation. Below I have listed the Visual Basic, C# and C/C++ Syntax for calculating a PComB Checksum. 1 - Calculate the Sum of the Byte Values in the Section (Meaning add all the "Bytes Values" together to make one big number) 2 - Take this Sum of Byte Values and Calculate the Modulo of 65536 ("Byte Values" MOD 65536) - This makes the Checksum's Maximum Value a Two-Byte Unsigned 16-Bit Integer 3 - Two's Complement of the Calculated Modulo Value - Invert ("NOT") the Value and Add "1" For the below examples, the Sum of the Byte Values is "<BytesSum>". Visual Basic (The Result 'checksum' is a UShort): ================================================= checksum = (Not (<BytesSum> Mod 65536)) + 1 C# (The Result 'checksum' is a UInt16): ======================================== checksum = (~(<BytesSum> % 65536)) + 1; C / C++: ========= checksum = (~(<BytesSum> % 65536)) + 1; Hopefully this is the information you were after! If you are still having trouble, maybe post some of your code so I can help explain things better Cheers, Ash Neilson

Nice blog entry Saragani! I have been looking at using the SD Card as a way to store history for MI / ML values, then transfer them from the SD Card to a remote server for graphing I just noticed that the latest SD Card Suite uses a version 1.0.0.31 of the Unitronics.ComDriver looking at the properties off the DLL. Are you planning on updating the available Source Code + DLL from the downloads section any time soon? Looking forward to the next blog entry!

Cara - You learn fast! I wasn't going to post anything about the UDFB's, but it would be a matter of hours before someone did I would trade my right arm for UDFB's if it wasn't for my job that requires typing

I was more thinking down the lines of Computer software to compliment or "Enhance" the Unitronics OPLC range. But since you brought it up, what is your reason for having Profibus or Profinet implemented in a Unitronics PLC? I find between Modbus, CANbus, CANopen, Unitronics Protocols and the ability to do a Raw Serial or Ethernet protocol - that I never come unstuck trying to talk to something! Basically everything on the face of this earth that is related to PLC's / Automation supports Modbus, CANbus or CANopen

Thought I would start off my blog with some thought generation! What sort of Technologies / Languages are sought after these days? I am basically interested in what any of you more "Techy" Unitronics users prefer as a Software Development language. My reason for this is to see what libraries / applications to support Unitronics hardware are missing on Non-Windows or Non .NET environments Do many of you long for a "Remote Operator" app on Mac or Linux (Maybe even the iPhone). Do many of you wish the .NET Communication Library was available for Java or Python (Or the language of your choice). Comment your ideas, thoughts, criticisms...

Woohoo looking forward to getting some blogging done! I have to say this new Forum beats the old one a million times over!!