dahnuguy

Use the function "Immediate Read Input" Read the help file on immediate read. If you don't interupt the PLC when a pulse comes in, you could miss pulses during the scan time. There is a cost to using the interrupts, it will slow down the program, but if you need it, you do it.

no You want a relay out if you want to send your own signal through the output. Or you could hack the PLC and pull the supply side on the transistor out and put your signal in. While your in there, might as well change the transistor to a FET , might need to add a resistor so the gate gets the right voltage. Should be fun.

I have used V130 and V350s and one V570. I only had the DT issue on the V130 , but I don't use the methods that cause the problem anymore, so I don't know if it would be different in the others. I did not consider that it could be processor specific. I always viewed it as a software issue. But you may be on to something.

If I recall correctly, you reported using an HMI bit to initiate the DT function. HMI bits are very similar to a positive transition bits, only worse, as the HMI screen changes the HMI bits are cleared, not at the end of the scan like a positive transition. This little nugget gave me a bit of difficulty for a while. And I saw the DT issue with a very low scan time, so I don't think it is scan dependent.

Scan was read from the SI "scan time" I was never terribly interested in nor had the time to launch a full scale investigation as to "why" any of this was happening. However, after that project was done, I ran into the same exact issue on a totally different project. The second project was much less complex, used no interrupts, or immediate updates and the scan time was less than 6 ms. This is when I implemented the "rules of using data tables" No leading positive transition bits. Only one DT function on a line, maybe 2 if you have to, but verify it, and never 3 or more. If you want the DT function to happen once, set a bit in the preceding rung, use the contact from that bit before the DT function, then reset the bit at the end of the DT function. If you follow those, you have a better chance of robust DT function. I have had no issues since I started doing this. Anyone should be able to repeat these issues. Get a program scan up to around 5ms and add 5 DT functions to a line with a positive transition bit. Even better, use an HMI bit. Now put some ever changing data in the DTs. One of my favorite test data is variations of the RTC. Now go look in the DT in "online" mode. You might find that some of the data is not there. Now try to send that data over CanOpen while it is changing for extra fun. Once you are aware of the issue, it isn't difficult to work around it. Its not a big issue at all. But it is maddening when the documentation and help desk tell you "it must not do this" and that's it. I might have some time this week or this weekend to post a sample so we can all look at the same thing and discuss it. Maybe it's just something I do that causes the issue. Ok maybe it's just something I and TMoulder do.

I think part of the problem was also because of the complexity of the program. It had around 2000 kines of ladder several DTs and several FIFO DTs , one DT had 1000 rows used as a FIFO. The scan time was 15ms. And there were 6 inputs used in an interrupt routine for measuring fast counts of flow meters. Not sure what specific thing made any difference. Not sure if any of it made a difference. I am pretty sure we discussed this when I was having the problem. I sent some examples of the rungs that did not work back then, but a solution was never found. So I found a way that works and let it go. Now I just follow a couple simple rules I have discovered to make it work better. If I have time, I will try to simulate the problem and post it.

The screen acts like a pulsed input or positive transition. DTs don't like that.

I had the same issue. I got the same answer. "It is immediate" you can be sure. But its not, at least not always. SO I had to study it myself and here is what I found to be true. If you use a positive transition bit in front of any data table function, your success is not guaranteed. Some number of the DT commands will not happen. Also if you put multiple DT functions on one line, sometimes the first command will execute, but the last one will not. I was doing both of these things. Drove me nuts. If the positive transition is true for the whole scan, and ALL the DT functions are done immediately EVERY time, then it should work EVERY time. But it doesn't. Now I needed the function to happen only once with specific data RIGHT NOW if X was true. So I set a bit to initiate the function and place the DT command right after the set bit and then placed a reset for the first bit right after the DT function. This worked every time with out fail. I also have added an extra MB to the data just to mark if data was recorded. I use this extra bit to trigger my FIFO to shift data down one row. That way I can always look at the same column of data to see when something is written to the row. Some data might be blank sometimes and most of my data are integers so it is easier to have that extra MB to compare with. The data tables do not work the way UNitronics thinks they do. Or at least not he way they explained it to me.

Using the latest version of Visilogics, and a V350. How do I use a PID to control motor speed? How do I control anything with PID that requires an up and a down control? How do I heat to some setpoint and hold it there and keep the temperature from climbing? Can I use 2 PIDs and have one oppose the other? I had this thought, but it may not work. Is the Visilogics PID one way only? Is that the end of it?

To control a temperature I would imagine. Like with a 2 way heat exchanger. Steam and condensate piped in one way, cold water and drain the other way. Holds temperature to a setpoint like heating 2000 gallons of liquid to 200 deg F and then hold it there without going over for a period of time, them bring the temperature down in steps or b a ramp to 100 degreees F and hold it there, then cool it down to 70 degrees F and hold it there. You can't do that with a one way PID. I would like to control a ,motor speed with PID both acceleration and deceleration. Currently as I understand the Unitronics PID, we can control up to a setpoint and once the PV exceeds the setpoint, the output of the PID just stops. Which would work for heat only. But does not control the motor very well. Nor would it stop the temperature from continuing to climb above setpoint. What would you do in Visilogics to heat to a setpoint and then stop the temperature from continuing to climb? Just wait and hope it cools off by itself? What about a chemical process that needs heating and cooling to maintain control? Is this one way PID control just a limit of the software? Or do I not understand it correctly?

Thank you for the response. The current application is an embedded processor with 2 can chips and some I/O. The transfer is slow due to throughput issues. But delays could be decreased if I could send more data per message or in each PDO. Other projects might include Beckoff terminal modules. I am sure Beckoff has modbus. I am unsure why the embedded device uses canbus. I recall that some other I/O was canbus enabled and the idea was to have one big canbus network with everything on it. But Unitronics slows down the response time due to limited data per PDO and only being able to send on every other scan and then the embedded device restricts throughput, so it is not feasible. The real restriction would be if I try to use 100's of I/O on one can node with the Beckoff module and a V350 with canopen. There are not enough PDOs to address the I/O. There might be other reasons this would not work. There might be a canbus limit that restricts the number of I/O per node. I am a canopen novice. I also thought about using ethernet instead of either "bus". The problem is I have to buy the hardware, then spend a couple weeks discovering what is not in the documentation and then finally get it to work and then decide which I want to use. None of that is going to happen. So I am stuck with canopen. So I am just trying to get it to work better with Unitronics and not overlook some detail. I think I can speed up what I have now by changing the way the data is sequenced. I have used Modbus, I think I like it better than canbus.

Is the limit 4 PDOs per node? At 8 bytes per PDO that is 32 Bytes of data sent to each node. Is this the maximum limit of data that can be sent to one node? Is there some way to increase this number? I realize I could play some tricks and shuffle data into a set of transfer bytes,( I could even increment down a row in a data table and put the row data into a transfer array and then send it, but this would be multiplexing and slow and would confuse the receiving node as well, some receiving array would need to be set up in the node and then parse the data using one of the pieces of data as an index or control word.) Direct transfer with canopen and Visilogics is tricky enough though. Just wondering where the limits are. I guess ethernet would be easier with 50 variables per message. or am I missing something?

I am using a V350 to send and receive data from 2 can nodes for the purpose of I/O expansion. If the unitronics expanded I/O were more compact, this would never have started. The Unitronics I/O could be like the Beckoff terminal modules. That would be nice, but anyway............ I can send 8bytes of data with one PDO. I am sending a speed reference to 2 motors for differential steering with two drive wheels. (time sensitive data) If I change the data during the same scan as I want to send the data over canopen, the data is "zero". (This is confirmed and discussed with Emil, this is not speculation. I spent a long time nailing that down. The issue is the fact that the canopen PDO contains a pointer to the data and does not grab the data and put the data in a buffer to send, it only has a pointer to the data. And if you are writing to that memory location when the canopen PDO is actually sent, the data is not available and a zero is sent instead. The canopen PDO is not completed at the time the command is called in the ladder, the actual send happens sometime during the scan, somewhat independent of the ladder.) So I must not update the data on the scan that I send the data. So now my data update is every other scan. I also must send other data in other PDOs. So currently, I have a bit that allows sending can messages every other scan and then only allows updating the data on the off scan. Then I send PDO1 , scan update data, send PDO2, scan update data, send PDO3, scan update data, repeat................With a scan time of 10msec, it takes a relatively long time to get back around to the speed reference in PDO1. By the time the data is refreshed it is too late to work properly. There are other issues that contribute to the problem, but this is the canopen Unitronics portion of the issue. Questions: Is the canbus buffer 8 bytes total, or 8 bytes per PDO? Is there a separate buffer for each PDO? I think there might be separate buffers, but I am not sure. Can I write all the PDOs in one scan ? This would send for example 8 x 5 bytes total, but with 5 different PDOs. If this is possible I only have the issue of not being able to send the data every scan, but this is still much better. So I hope I will be able to send all PDOs to both nodes on every other scan. I would prefer to be able to send on every scan. When I get some time to return to this hardware, I will see if I can move the PDO send section to the last Subroutine or try to find some way to make it more solid. I remember something about some of the canopen blocks must be in the main, but I think the PDOs can be sent from a SUB. I haven't looked at this in awhile, and it is coming up soon. I will revisit the software, but I wanted to get a head start on some feedback on these issues as I begin. Thanks,

V350-35-T38 What is the difference between PWM using a HSO and PTO? I am playing with a PWM output now. Looks like it works fine. But PWM is different from a Pulse Train for a servo. I see a different area in the hardware config for PTO out and PWM out, but what block does one use for PTO in the software? Do we set up the output for PTO in the hardware config and then just use the same block in software as the PWM? Also, what is the easiest way to convert the PWM out to an analog voltage? I was thinking of adding a resistor and a capacitor to the output terminal on the V350. WIll this be a problem for the V350?