Jump to content

Damian

UniStream & UniLogic Beta
  • Content Count

    532
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Damian

  1. Open and close times were too long eh? I was under the impression that these instructions were done in a scan. I am not surprised to learn otherwise.

    I have looked and I do not see these Fast open and close blocks you reference. I am very interested in these for an upcoming project. Are you saying that the open and close socket instructions have been changed and are now faster / better and are the standard functions in the new software?

    I looked in the "new Immediate blocks" under "Utils / Immediate" I don't see anything there about ethernet sockets. I don't see anything under "Coms" or "FBs" either.

    Or are you referring to a subroutine that someone at Unitronics wrote for you?

    Would be too much to ask for you to post a striped down program that includes your open close sockets? Maybe a subroutine of your fast coms?

    I went through this same exercise a couple years ago and spent a lot of time on the coms. I could never get it to work the way I wanted it to no matter what I did.

    Thanks for the information.

    Well it can't be "done" in one scan. At least not reliably. Mostly because to complete a connection requires some time, and also depends on the one being connected to. I was complaining that it was difficult to share a socket on the Vision product and that I knew it wasn't a result of the slaves I was talking to because I used something else to talk to them and it was an order of magnitude faster. So the delays were in the Uni. The new FBs are much faster and makes sharing a socket much more viable. Especially with the 4 socket limitation. I appologize, but I had wrongly assumed this was released. So I would not recommend using it unless you are willing to be a Guinea Pig for it and possibly limit yourself to a specific OS and Visi release. They may not be "better". It establishes a connection faster, but I am sure to get something you usually have to give something else up somewhere else.

    I will make you a stripped down version of my socket routine. There is nothing novel going on in any of them, but it has been out in the wild now for a few years on several machines and has proved robust.

  2. We did not release them with a version because they have not been fully tested by us, although Damian has--apparently--been using them.

    .

    Doh! ................ Sorry. I don't remember having had to do anything special to get them to show up last time, so I assumed they had been officially released. My appologies.

    Regarding the OS compatibily, I am not certain to be honest. I went a while sticking with an older version of Visilogic so It may not work for all I know.

  3. Calculating things out for the RJ1P puts the impedance of the SSR right at 500ohm. And you pointed out, the Unitronics is looking for < 500ohm.

    500 ohms is pretty typical across all manufacturers for a max impendance for an output like this. I would point the finger more so at Carlo in this case. They shouldn't have to design it with so much impedance.

    The power supply is a valid solution, but I think I would put more effort into finding better SSRs.

  4. You'll get no argument with me . I am not fond of CAN. If you consider the low cost (cabling, switches, connectors, electronics, etc) , speed, robustness, and interchangability of Ethernet I don't see why anyone would use CAN in a new implementation unless they have just such a huge installed base that it is the only thing that makes sense. I would like to see Unitronics make an Ethernet version of the A2 for the remote I/O. In fact I often wish they partnered with a company like Beckhoff or Wago on their I/O and just focused soley on the HMI/PLC. Would love a Unitronics that you could actually snap in Beckhoff modules. You could probably get about a dozen of them across the rear of a V570.

    I never had any issues getting all 4 sockets to communicate simultaneously, but I do admit to spending quite a lot of time on the communication routines to make sure they were optimized for speed and robustness. Biggest issue I ran into was when I needed to share a socket the Open/Close times were too long. They made me a FAST socket Open/Close block (look at the new Immediate Open and Close blocks) that allowed me to overcome that. Up until then what I would have to do is make an "electronic distributor cap" of the sockets such that it would rotate through 2 or 3 of them and start connecting to the next one while I was reading the current one. That was a lot of ugly indirectly addressed code!

    I had the new Beckhoff servo terminals quoted a couple weeks ago.

    http://www.beckhoff....9000_bk9050.htm

    The rep told me that I would not be able to use these with the Bus coupler and that there were other modules like this that also were not capable of it. They quoted a CX5020 instead with an EthernetIP slave driver. I have requested a compatibility chart from them, If I get it I will share with you.

  5. They have a separate document related to the M90 series

    http://www.redlion.n...-Unitronics.pdf

    The driver tested with the Vision series is

    http://www.redlion.n...t/G3_PCOM_A.pdf

    The difference in the cabling is only that on one they show the direct connection between the two whereas on the other they show it using an intermediate RJ to 9pin cable in between.

    I believe the driver labeled "Master" is the one required for the M90, and "PCOM ASCII Master" for Vision. See below...

    In any event, I was able to get it working fine with the same setup in his original post.

    Uni RedLion

  6. I wouldn't consider your signal as PWM. The speed of the signal is probably too fast to read reliablly. It might work, but I doubt it because you're right at the edge of the limitations. Scan time will be a huge factor so your program size will have to be kept at a minimum. It would help if you had a faster processor like with the V570. Too bad it is just not a simple communication signal going RS485/RS232.

    Depending on the scan I think it will be difficult to tell the difference between a long 2ms pulse and a shot 4ms pulse.

    Maybe someone will have a clever idea.

  7. It works for me using all the same settings and the same wiring you show.

    Make sure your dip-switches for com2 on the V570 are set to RS232 and not RS485. It should go Up, Up, Up, Down, Up, Down {up=on dn=off}

    Re-check your wiring. These little RJ11 jacks are easy to transpose. In the Installation manual for the V570 they show the pins in order 1-6, but the picture is rotated so 1 starts at the bottom and 6 is at the top.

    If you want, post your files and I can take a quick scan to see if I spot any program/config issues.

  8. Hi,

    Can I participate to this interesting discussion?

    OK - LC3 has one A/D converter. There is built in buffer for filtering.

    In LC1 the buffer is filled in the first half secind after powering the system and thhen the result is given in FIFO. When you have 3 channels, each time you switch between them you need to reset the buffer and to wait untill it will fill again. That's why the min settling time for two and 3 channels is way greater than the one for one channel.

    Small tip: In advanced functions of FB Loadcell you have option "Disable all other chanels" This way you make one channel only runnning in LC3 with the speed of LC1. This is not universal soluiton, but if you don't need more then one chanel at a time, you can use LC 3 and in each moment switch to the relevant chanel. With this easy lader "gimnastics" you will get 3 x LC1 in gthe place and price of one...

    Emil, Thanks for the detailed response. It was definitely more along the lines of what I was looking for. Could you elaborate more on what this buffer is for and is doing?

    Thanks,

    Damian

  9. Hi Simon, Thanks for your input. It is always appreciated.

    I did expect that they were multiplexing a single A/D converter, but the jump from 12.5ms to 675ms doesn't make sense to me at all. Why would adding one channel add 650ms to the cycle, but adding a third only add 337.5 ms? And why so long in either case? The price of the LC3 is very attractive if you compare it to purchasing multiple load cell amps, but I find myself leaning towards doing that and just mounting a standard analog input card. From my standpoint they should have three seprate A/D converters and multiplexing the data side instead. In this day and age what does an A/D converter cost?! Even the expensive ones are cheap.

    1. the slower sample rate will mean much fewer values to work with. So if the base sample period is 675ms, you should expect strange results if you settling time is less than this value, and it probably should be 5-10 times the sample time.

    I'm not certain how they are doing the filters, but It would seem the sample times alone almost render the filtering useless when using more than 1 channel. Unless your process is really slow.

    2. I don't think the statement about independent setting of the filter parameters conflicts with the statement about the interaction between base sample time and filter depth.

    You're right. The act of adjusting the values of the filters on each channel does not affect the filtering globally. The act of adding more channels does affect the filtering. I was reading more into it than what was really being said.

  10. We are looking at using the LC3 to measure a pair of load cells at speeds where I am concerned about the response time of the Unitronics system. We got bit a while back by not paying enough attention to conversion times of certain modules and found out that some were quite long.

    Anyhow, I want to make certain I understand clearly the response I can expect when measuring 2 load cells with the LC3.

    The published spec is 12.5msec. So the first question is is that total or is it per channel? Will it actually do 12.5msec for both channels independantly, 12.5msec per each channel is use (total 25msec), or worst of all 12.5msec per each channel whether they are used or not (32.5 msec)?

    I also found this disturbing spec in the help file.

    Note

    Minimum settling times for projects using multiple loadcells are


    • 12.5ms for one active loadcell

    • 675ms for two active loadcells

    • 1,012.5ms for three active loadcells

    What does this mean exactly? Is this settling on the electronics end? The processing/filtering/program end? How can it go from 12.5ms to 675ms?!? What is the settling time indicating and how is it related to the conversion time? How does this correlate to using multiple LC3 modules. Does the above minimum settling times apply on a per module basis, or does it continue to get exponentially worse for every channel I use?

    Could I use two LC1 modules instead, and get 12.5ms each to elimate the severe degradation in performance.

    On a different but unrelated note, we had a customer considering these for their high speed check weighing machines.

    It seems as though the IO-LC1 and IO-LC3 are not suitable for high speed check weighing applications based on how slow and unresponsive the electronics are.

  11. Well, you you need 15/3 = 5 total LC-3 modules. So as long as you are under 8 modules with the rest of your IO requirements you should be fine.

    The V1040 is only getting data from the RC1, it doesn't really care what it is on the other end. The processing for it is no more intensive than any of the other modules. The more pertinent question is can the RC1 handle 5 LC-3 modules. I have never used that many, but I don't see why not.

  12. Hi Damian

    I had a lot of problems recently with a touch screen button with jumps to various displays.

    To solve this I had to stop and initialise the plc after I loaded a new program to the PLC.

    It seems that some MB's will remain high from a previous program and will not reset if they are only linked to a touch element.

    Hope this helps.

    Regards

    Denis

    I have never experienced the problem myself. Usually when people new to Visilogic have these problems it is related to screen calls in the ladder that are not one-shotted. Sometimes it is also because they press a button on screen A that takes them to screen B and their finger is still on the screen under a new button that might call a different screen. Goofy things like that.

  13. Some things to look for..........

    Are you making any screen calls in your ladder? If so make certain they are all one-shotted. You might have a situation where you are re-invoking the same screen over and over again.

    Are you writing to system bits? Some system bits control or affect the behavior of the screen.

    Look at these for control and status

    SB6

    SB17 through SB39

    SB73

    SB76

    SB92,93,94

    Happy hunting!

    If all else fails, post your program and we'll help you dig.

×
×
  • Create New...