Damian

Go wireless. Put a bluetooth or Wifi adapter on the RS232 port and upoad the data that way. If you go Wifi you could patch it into your main network and then you wouldn't have to leave you seat.

It sounds as though there are some severe isolation issues with with the hardware. It does not sound like ports1 and ports 2 of the v1210 are isolated. I am curious if you just have a defective piece of hardware, or if this is a problem (like Joe suspects) with that entire line of cables.

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.

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.

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.

Well that is strange. Beckhoff's website is flakey. The inner page and the outer page act separate to each other. I had copied the link out of the address bar with the servo module showing, but the address bar did was still on the Bus-coupler page. Anyhow, i was talking about the EL7201 http://www.beckhoff.com/english.asp?press/pr4510.htm

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.

It should be fine using Modbus TCP/IP. I assume you are deliberately avoiding a CAN connection. Keep in mind that some of the specialty modules for Beckhoff will not be compatible with a Bus coupler.

RM1E48I50E isn't coming up as a valid part number. Do you have a link to the data sheet?

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.

Can you provide the exact part number of the SSR?

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.

Nacho, the wiring he lists in his post is correct. The document you linked is for a different protocol and talking to an M90 series controller.

Could the Accelerate FB be used with an acceleration factor of unity?

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.

Keith, Good to know (well, good to be aware anyhow.). Curious, were you using a laptop? If so, were you running off the battery or did you have it plugged in?

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

Perry, Thanks for your 2 cents. It definitely gives me a fuzzier feeling about using 2 LC1's. What kind of accuracies are you achieving on your fill weights in terms of gross percentage? Thanks, Damian

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

I also found these two seemingly conflicting statements in the specification sheets The number of Loadcell inputs used per expansion module affects the sampling rate for each of them, resulting in lower filter depth and effective resolution. The filter settling time can be programmed separately for each Loadcell input without affecting the other(s).

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.

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.

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.

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.

Perhaps it was assigned to an analog input?