Jump to content


UniStream & UniLogic Beta
  • Content Count

  • Joined

  • Last visited

  • Days Won


Damian last won the day on July 3 2017

Damian had the most liked content!

Community Reputation

24 Excellent

About Damian

  • Rank
  • Birthday 08/06/1974

Contact Methods

  • Website URL

Profile Information

  • Gender

Recent Profile Visitors

8,231 profile views
  1. A bit of a weird situation with the unit in title. It is installed and working as you would expect (new application, just programmed this week), but I noticed some odd noises coming from it. I disconnected all the connectors and cables except for the 24VDC supply and it still makes the noise. When I cycle power to it, it is quiet up until it completely finished booting and then runs the application. As soon as the application starts running, the unit starts making the crackle sound again. There are not any relay IO, so it can't be a chattering contact. It is hard to tell if it is the speaker or something else. Attached are a couple videos where hopefully you can hear the audio OK. Any ideas on what it might be? UniStream Snap Crackle Pop.mp4 UniStream Crackle.mp4
  2. Jumper settings? Wiring and common connection? MI10 overwritten somewhere else in program?
  3. BTW, I tried just doing a small subset (for example just MI) and it still choked on them.
  4. Well ........... all of them really. M, MI, MF, ML, DW. It is nice to have a backup of all the operand values in a PLC. I have had it work fine on some computers, and not at all on others. Hard to understand why since if it is truly just creating a simple CSV file it should not have anything to do with the OS or installation.
  5. How do I get around the "The CSV file you have selected cannot support the exported values" message that pops up every time I try to save the operands?
  6. Yes, my Main subroutine never has any code in it other than calls to other subroutines. One of the very first is the call to the "Inputs" subroutines, and one of the very last is the "Outputs" subroutine. I would say first that you should specify what you regard as an issue. But beyond that, I would contend that there are certain caveats with positive and negative transitions that in fact make buffering inputs and outputs even more valuable, not less. It gives you much more control. With ladder, the traditional definition of the scan had the physical IO only updating between single scans of the program. This way you could rely on knowing that the physical Inputs would not change state while your program was in a scan cycle. Some modern controllers, (AB Compact Logix) no longer adhere to this. They have what is considered an asynchronous scan and results in the I/O possibly being updated mid scan, perhaps even multiple times per scan. At face value it may not seem like that would be all that bad of a situation, but in actuality it creates a host of complications and extra considerations that need to be made while coding. Most of us mandate buffered IO on a Compact Logix system as a result, so that we know that we are looking at one single snap shot of the IO for every single scan. The use of buffering has created a rift where most are usually adamantly opposed to it or fervently for it. Those that oppose it often cite extra time to code, extra memory use, and believe it adds a layer of complexity that doesn't need to be there. Those of us who are for it feel the cost of the memory and time is generally negligible and is won back over time by having a more robust system. We contend that it makes the code simpler to understand, not more complex. It also makes it nice if you blow an IO point on a card and want to move the logic over to a spare. With the buffering you simply change it in one spot and your done. The retort to that is usually that you can simply do a find/replace just as quickly. Well maybe, but what if you want to for example debounce that signal. All of a sudden find/replace falls flat. Whereas I would simply go to my buffer and put a timer between my physical IO and my buffered IO and it automatically takes effect for all instances of that signal. And by the same token, this is where some other nice aspects of buffering come in to play. The buffering doesn't need to be a straight one to one mapping. It can serve the function of creating ON debounce, OFF debounce, ON and OFF debounce, one shots, and signal combinations. Having this stuff in the buffer removes it from the actual code so that the code is easier to read and understand. I often find reason to have an input debounced in both the ON and OFF direction, and the code to do this is will just clutter the actual sequence program. I also often buffer things in multiple ways. For example I may have a normal instance of an input and a one-shot instance of that same input. This serves two nice functions and illustrates why I think it addresses exactly what you were alluding to with your question. For one, you will find in the documentation that Unitronics discourages overuse of P and N contacts because they have a detrimental effect on the PLC resources. If you need to use the positive transitions of the same signal several times in your program you are much better off using one transition contact to control one normal buffer bit and then just use regular contacts throughout with that buffer bit. You can make it clear with a naming convention (ex. P Control Start PB) that it is transition. The other benefit is you have complete control over how that transition is refreshed now. If you recorded that transition with the buffer bit right in the first subroutine you can count on the fact that that buffer bit will carry the same state throughout the rest of the scan, no matter how many times you jump in and out of subroutines. That is of course unless YOU modify that buffer bit elsewhere. And not to be forgotten, the combination signal. What is this? Well possibly it is making more inputs out of fewer. Perhaps you have three aux guard contacts coming into the PLC in separate inputs. It might be beneficial to have one single signal that tells you if all three are on. Or, perhaps you have a mulitplexed signal coming in. Maybe it is a selector switch for a product select where product one is both off, product 2 is one on, product 3 is the other on, and product 4 is both on. Now you can make four buffered inputs that decode this one for one and product one selected, product two select, etc. Again, stuff like this tends to just obfuscate the sequence code. Perhaps you have buttons on the HMI that perform the same function as physical buttons, then you combine these and have both signals controlling the same buffered bit. I could go on and on. This is again another example of where buffering is handy. It allows you to write code that is non-hardware specific and then just attach those mapping in one spot. I am not certain what you mean by the input format is different. Perhaps you could clarify? What kind of problems are you having?
  7. In addition to what Joe points out, you also need to make sure your common fault MB and the actual individual fault bits are not continously active. Otherwise it will just continuously reinvoke the screen call and cause all sorts of problems. The V570 has a decent size screen. I can't imagine not just putting all four of these on one screen and let them all show simultaneously. Your customer may be making your job more difficult by thinking that separate screens are "simpler"
  8. It sure is. Obviously you will need to find a wireless transmitter that is compatible with something you can get on the V570 (RS232.RS485,Ethernet, etc). Only word of caution is about speed. The analog inputs on the snap in modules in general have better performance. Make sure the conversion times and filtering are acceptable for your application. If you have a slow process there are no worries. If all of this happens in less than a second you will have to do your homework.
  9. VMware has a free utility called VMWare Player that allows you to run a windows VM on a MAC. The only catch is you need a copy of windows to install on that VM.
  10. This is happened to me before on a V1040 and I ended up having to re-install the OS. A colleague of mine also had a similar problem as this and he ended up having to pull the Ethernet adapter out. Don't know if you are using ethernet but it might be worth a try.
  11. Flex, It is definitely helpful. I myself am not a fan of how visilogic handles retentative values and especially that of timers. I would much rather see the "initial values" method completely abandoned in favor of the "current values". When I want to make abosolute certain I am cloning the operand values I use the "Remote Access" utility and uload all those values into a csv file. I also do not reference timers directly but instead buffer all presets using MI operands. This circumvents some of the flakey behavior you note above.
  12. Emil, Excellent description. Thank you for taking the time to explain it so thoroughly. Damian
  • Create New...