Jump to content


UniStream & UniLogic Beta
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Damian

  1. Hi Tim, I always found that you had to look for not only the "busy" bit, but also the "status", "sessions", and "acknowledgements". As you mention, the busy may or may not ever be seen. However, if your acks have increased you know something is going on. If your sessions have increased and you don't have any comm errors you pretty much know that the you blew by your "busy" The code below has yet to fail me. XI2 is my sequence indexer. I have a watchdog checking to see if it gets stuck and to take corrective action when possible.
  2. This is a common gripe............. Why are we forced to select a FIXED color for the Bar Graph and TANK display elements? It is very natural on most other HMIs that you can select thresholds where the color of the device changes. For instance ..... I may want to show water level in a TANK. If the level drops below a certain point, I may wish for it to display Blue for "too low" when it drops below for example 10% full scale. I may also wish to have it go RED if it gets above say 85% full scale. This functionality is part of virtually all other HMI softwares that I can remember. For an easy fix, why not just allow us to assign an operand for the color? This way we can pick from a color pallet and then just use some ladder code to handle the color change. At the moment, the only way I see that you can achieve the same effect is by creating three identical elements, size and position them perfectly over each other, assign them each a different fixed color, and then create a bunch of code to hide the two or so that are not in the current operating range. This really should be built in. The Bar Graph and TANK should have selectable color range just like the meter control. If interested, I can send some screen shots of how other softwares handle it. D
  3. Hi Emil, His first post actually has his wiring Diagram. It is a three wire RTD. It does appear to be wired correctly (assuming they followed the print). Good Idea with the glass of water! Damian
  4. Hi, Some questions: Are you using the RTD just to read temp, or is the V230 actually controlling the water temp somehow? If the temp is fluctuating, has it been considered that the fluctuation might actually be in the the temp of the water in the pipe and that the sensor is in fact working just fine? Is the cooling pipe such that you are guaranteed the RTD is always completely submersed in the water? (ie, possibly cavitatation, possibly air pockets if horizontal and RTD enters from the top.) What is the frequency of the "flucutations"? Describe them a bit more? Is it sinusoidal? sporadic? Does it occur maybe when a pump motor kicks in? Are you using a shielded RTD? Have you kept it isolated from high voltages? Is the V230 mounted on an enclosure and is the temperature inside this enclosure stable? Is the tip of the RTD in direct contact with the water, or does is just sit in a T/C type well? All the documentation of the module is available right on Unitronics Website. Not sure why you are having such a hard time finding it. Yes, you definitely want to make sure you have all the settings and jumpers set properly. Make sure the operands you tied to the analog input are not being used somewhere else in the program. Hopefully one of these might be the cure. D
  5. Hi Fabios, If I understand correctly, the source of the issue isn't so much that the frequency of the pulses is too fast but rather the pulse "ON" time is too small as a result of the bolt being too short in width. The good news is, this should be an easy problem to fix. Simon already hit the nail on the head. Instead of referencing the digital input directly, you will instead need to reference the input indirectly by way of the high speed counter. Assuming you already have the prox wired to one of the high speed inputs, go to the HSC with with reload in the hardware configuration. Select that input to be a HSC, and do not select a frequency measurement. Now you will use the "reload event" M or X bit in place of where you had the contact for the prox in the code. With the high speed counter, it gives you some flexibility. You can instead have it count to 2. This means that your measurement code would need to divide by 60000 now instead of 30000 since you are only measuring between every other prox. This will also help you get better RPM read resolution IF THE SPEED IS UNIFORM AND CONSTANT during the measurement. Sort of in the same way you can measure the width of a sheet of paper by measuring the thickness of a reem of paper and dividing it by the number of sheets in the reem. Another consideration, many sensors can be purchased that have a built in time delay. If you had one of these, you could adjust such that the prox output stays on for some minimum time. This is used often in high speed registration applications where things go by too fast for the PLC scan to detect reliably. You could also put a cap on the bolt to make them "wider" to the prox. To get better resolution on the above, you might also need to make the HSC interrupt driven. In this case, you would want to use the "Interval" blocks instead of the 2.5ms clock to take the measurement. That combination is probably the best you could do with the system you have as far as performance. Good luck, D
  6. The following is straight out of the help: System Bits General, SBs 0-15 # Description Turns ON when: Turns OFF when: Reset by: SB 0 Always 0 Never Always SB 1 Always 1 Always Never SB 2 Power-up bit Power-up occurs, for 1 scan SB 3 1 second pulse SB 4 Divide by zero SB 5 Outputs short circuit SB 6 Keyboard is active SB 7 100 mS pulse SB 8 Battery low SB9 RAM failure :Bit value is not 0 or 1 Battery needs to be replaced, or RAM has failed Battery and RAM are functioning Reset by user: via info, or Communication SB 10 Float Error By OS when the result of a float operation is an illegal float value. Error code is in SI440. By user, or at power-up. SB 11 User Stack Overflow SB 13 ON at Rising Edge of SB3 (1sec pulse) Turns ON when SB3, 1 second pulse, rises OS SB 14 Calculate current controller temperature (not supported by V120/130/350) By user. When SB 14 turns ON, the value in SI 14, Current Controller Temperature updates. By OS OS SB 15 ON at Rising Edge of SB7 (100 mS pulse) Turns ON when SB7, 100mS second pulse, rises OS
  7. On a somewhat related note ..... I don't know if anyone here has also use the RedLion Crimson 3 Software before. They don't have any real "help" files at all. If you click on help anywhere in the software, it boots adobe and loads the first page of their operation manual. When I asked them their answer was, this is the way it has always been, and this is the way it will always be. One thing I really like about Visilogic is the great lengths they went through to try and make sure that help files are very well presented. There is a good balance of explanation and example. They often give graphics and screenshots. It is rare to find something undocumented, and even when you do, they are very quick to correct it if they are made aware of it.
  8. Our responses are essentially the same. After some quick research, the "extra" 10h is actually correct. It is called DLE ESCAPING or DLE STUFFING Any time the DLE character occurs within the Data, Address, or Mask Field, it must be doubled so that the controller does not misinterpret it as a control character. This still doesn't explain WHY the AB is choking of the incoming data. I haven't had time to work it out, but I suspect that the Unitronics function is not calculating the checksum properly when DLE ESCAPING occurs. I say this only because otherwise the framing of the data looks to be correct. The checksum gets tricky because it is NOT supposed to account for the "extra" DLEs when performing the calculation. Oddly, it would be expected that it would also choke when trying to access an address of of say for example (N7:16 > 1808) which are both on the "10h" list. D
  9. Perhaps also there should be some changing of the wording in the help regarding the MI's. From the help file......... "Memory Integers are 16-bit integer operands that may be signed or unsigned. The range of an MI is -32768 to +32767." I think it may be a misnomer to state that the MI can be treated as an unsigned integer. If it could be unsigned, it would indicate that it would have a range of (0 to +65536). Stating that you can treat it as unsigned gives the false impression that you could alter how the MSB is treated.
  10. Probably what is happening is since the MI is treated as a signed number, and you put 8000 hex in, it is treating it still like a negative number. The range of an MI is -32768 to +32767 8000h equals 32768 So you are probably shifting in an overflow or sign bit somehow. Whatever the case may be, technically 8000h is out of range for an MI. If you try to enter 32768 in decimal into an MI it will not let you. If you need all 16bits, possibly consider using an ML or a DW instead. D
  11. I believe TM originally requested this a long time ago, but I thought I might throw it out there again. It would be nice to have the ability to address INT and DINTS at the bit level. So just as we may be assigning a normally open contact "MB0", I would also like to assign a contact say "MI8.5" or "DW2.17". Using TEST BIT is clunky, time consuming, and takes up too much rung area, and while in Online mode is not as easy to see if it is testing OFF or ON. Even then it is only converting to a BIT operand with then needs also to be referenced again somewhere else.
  12. OK .............. The plot thickens. I instead tried again with my CompactLogix L35E. Everything all of the sudden was working great again ........ Until............ I tried some of the values you mentioned above and got Error Code 001F and extended error Code 0204. So, I have been able to duplicate your issue after all. This is all starting to make sense now. The reason I switched to Modbus regarding my earlier post was that I never could get the DF1 communication to work reliably. Now I finally know why. I had a hearbeat integer that would just continue to count up in the V570. This was so I could just look for a change in state on that integer to verify that I had communication. Now It is clear that my comms kept timing out because the number would eventually be read as one of the "hex 10 byte values" and cause the above mentioned error. I mentioned this way back in the last post of this thread http://forum.unitronics.com/index.php?/topic/74-the-modbus-blues/page__p__306__hl__df1__fromsearch__1#entry306 I now know it is the same problem you are experiencing. Judging by the old forum, I suspect this is also what was happening to JOEB http://www.unitronics.com/forum/topic.asp?TOPIC_ID=2462&SearchTerms=L35E D
  13. Please be sure to post the resolution on this. I did find an ML1400 to try out on it. I was able to write to the V570 with no issues. I was unable to get a read to perform without error. In info mode, monitoring the port set to DF1, I can see that the Uni is transmitting the characters. I can't say for certain just yet, but the size of the response seems much too long. I'll have to dig up the DF1 procol and compare the correct framing. I find this really odd because I have had this working in the past on a SLC and never had any transmission issues. On a side note................................. IF you don't have any other DF1 nodes you need to support, and IF your SLC5/03 has fairly recent firmware (within the past few years -- actually can be upgraded as well) and IF you RSLogix500 software in fairly current (within the past few years You can instead use the 5/03 as a modbus master. Same port, same cable, same everything. Just a software change. I have done this in the past and it works much better than the DF1. Another advantage of this is the Modbus address mapping in the V570 is much less convoluted. So if you have the choice between using the DF1 and modbus, IMHO I recommend simply switching over to the Modbus protocol. D
  14. Damian

    FOSS Logic

    TM, I think it is a great idea. Look forward to seeing it! Damian
  15. What piece of hardware are you using? Does the communication work of if you hook via 232 directly to one of the Uni's
  16. Hi Ofir, Using the SUCCESS bit for resetting the condition to ping only works if it was SUCCESSFUL. If it were SUCCESSFUL, I usually would not have a reason to reset and PING again anyway. It would have been more preferrable for the PING block to have had a "# of retries" similar to how it works from a DOS window. Thanks, D
  17. I am assuming that 6064 is actually 2064? My first suspicion is that the V570 is incorrectly interpretting the "0001" as an EOT. I wish I had my my SLC03 on hand so I could try and replicate the same error. Try changing the Unit ID. Also, what are your comm settings? (ie 19200,8,n,1) I seem to remember back when I fussed around with this that it was sensitive to a certain baud rate. Possibly changing them may help? Heres a link to some DF1 info regarding how the info is packaged http://www.iatips.com/df1_tips.html If I stumble over my 5/03 sometime soon I'll give it a try. D
  18. Hi Ofir, PINGING from the PC works every time. I did play around with this a little more yesterday. I have found that you cannot one-shot the PING block. Some of the operands that it writes to act a bit strange. I have found that if I reset the "busy", "success", "tx to rx diff", and the "error code" prior to re-enabling the PING block but on the same scan that the block will get stuck in the "busy condition". This is similar to what happens also if you one shot it. It gets stuck with the BUSY on. I am of course resetting the above values so that I know for certain that any non-zero values after that are "new" and not just left over from last time. Actually I am setting the "error code" to -1 since it was unfortunately chosen to mean "no error" as opposed to 0 meaning "no error" So since I can't one-shot the block, I need to know when it is finished. It seems like I have to check for two separate conditions. When the Busy bit goes back OFF, It looks as though I have to check for both the SUCCESS bit as well as compare the Error code to see if it becomes something other than -1. Am I taking the wrong approach here with this? From an intuitive standpoint, it seems like we should just be able to one-shot the block, get a bit back that says it is DONE, and also a bit back that says whether or not it was SUCCESSFUL. Thanks, D
  19. Hi Ofir, If you read above, he has a direct connection between the Unitronics and the controller. There is no PC/switch/firewall etc. in the system. He has already verified communication from the PC since as he stated before it does PING.
  20. Hi Stein, Where are you referencing that it should "zero" the operand? In all the places I have seen in the help files it says that it "initializes" the operand. "Initialize implies that it should take on the power up value. By the same token, It would be nice to have an element that performed both. Maybe keep the "reset" to set to zero and add a "re-init" that causes it to take on the power up value. The "reset" element is really handy and makes the code much more compact as opposed to using the STORE blocks. Thanks, D
  21. Something I noticed quite some time ago but never got around to asking about. When using the "Reset Numric" coil, by definition it should "re-initialize" the value of the assigned variable. However, instead, it always seems to just set the value back to "zero", regardless of what the "power up" value is. example. .. The power up value of MI5 is set to 6. PLC powers up, MI5 = 6 I set MI5 to 7 manually Then I pulse the Reset Numeric coil for MI5. I would expect it to "re-initialize" MI5 to 6. Instead it sets it to 0. From the help file "Select Reset Numeric, then place the function in the desired net. In the following picture, when MB 0 turns ON, MI 0 will be initialized." Is this possibly a bug?
  22. Hi Ziwi, No, 30000.0 was right all along. The numbers in my example were low because I was just using a push button to simulate pulses. I could only get about 2 presses in per second. When things start getting really slow, you also then have to worry about how consistent/accurate the trigger location is every time. It also relies on the speed being pretty stable and constant. But normally if you are looking for that kind of accuracy you would probably be hanging an encoder off it anyway. D
  • Create New...