cantcliff

Each method has it's ups and downs depending on the environment. We usually just tie the commons together here without issue as it's the easiest and we don't have any usual loads. Also we use lots of fuses to protect everything.

I know certain blocks need to be within !Main or scanned every cycle. Is there a list of blocks that need to be within !Main?

Question/Issue: Do certain function blocks only work correctly in the !Main Routine? Even if they are in a subroutine that is called every cycle? Hardware: V570-57-T10 with multiple I/O Expansions Hardware OS: 3.9 (06) Software: 9.7.44 Build 0 Had an unusual issue popping up while attempting to write a delimited line to Excel CSV, also ran into the same problem with the Num to ASCII function block. 1) Any time I use the Create Delimited Line function block using the System Date/Time SI's to create a custom string and three ML, then attempted to write out the results to the SD card, the date-time string would process fine but all the ML data would populate to Zero regardless of the value stored in the ML. Each line in the CSV would look like this: Example Bad Output: 2015-10-21-1507:36,0,0,0 2015-10-21-1507:39,0,0,0 2015-10-21-1507:45,0,0,0 2) Next I attempted to use Num to ASCII to create a string. The value stored in the target MI for the string always remained zero and attempting to reference the target MI for Create Delimited Line resulted in the same CSV output above. 3) Out of curiosity I moved the Num to ASCII to !Main Routine and for no apparent reason the target MI now populated with a results as intended. In fact, the output is now correct but only when I run the FB's in !Main, anywhere else and I get bad output. Example Good Output: 2015-10-21-1527:18,91.121,91.081,.0400 4) Additional thoughts -The routine that I'm placing the Function block isn't being called. Not an issue. I tested this in Subroutines that I know are being called, and regardless of which subroutine I put them in, they fail to function while all other logic in the subroutine performs as intended. The blocks only function in !Main Routine.

Background I'm working on updating some of our test equipment. The current setup uses two 20 gallon vacuum reservoir tanks, two manual needle valves per tank, 4 solenoids for tank vacuum controls, 2 differential pressure controllers with DC output, and one PLC. It also uses a very manual process for setup. My goal is to replace the main control box with two analog proportioning valves, 2 analog pressure transmitters, and one PLC with the PLC controlling the vacuum levels inside the tank automatically through data tables. I have a slightly different setup in testing right now but I'd like to get a finer control. Question What's the best way to control the process variables for two regulators using PID without creating a feedback loop and oscillation? One Valve would function as a cooling type PID (Reducing the vacuum level based on input), one valve would function as heating (Increasing the vacuum based on input)

I'm working on understanding the RLO to Bit function block, personal knowledge more so than application use. I think I have a fairly decent idea of the applications of it but I'd like to get an idea of an actual use on it. In my head it seems to be an unnecessary abstraction of other combinations of function blocks. Any feedback or application examples would be immensely helpful. Thank you!

You're getting the warning because there is a limited amount of Positive/Negative transitions allowed in the final code. Where it becomes an issue is when the ladder logic only shows that you used, for example, 8 positive transitions but the actual code compiles to 15 when it is converted to STL. This is quite common and if you use too many it's possible you will exceed the maximum number of P/N transitions allowed when the program compiles without understanding where or why. On smaller ladders it's usually not an issue but on larger ones it may cause unintended logic errors after compiling and uploading. You can reference PDF page 55-56, (Page number 48-49) of the ladder logic programming manual with the maximum number of P/N transitions you can use.

Typically if you overflow an integer data type it rolls over to it's maximum negative number and counts from there which can cause some pretty weird issues if you haven't accounted for it. What is the goal of the high speed counter? What happens with the count when you're done with it, or when it reaches a setpoint?

PID works best when you have a process running you want to keep stable around a set point. To match your case: The belt could have heavy items added to it that would slow it down, PID would adjust the output of the motor to keep the speed the same with the extra load, or would reduce it when the load was removed. Really you just want a ramp rate before you start your cycle, I believe the PTO functions might help you, but I might be wrong as I've never messed with them yet.

All things said the card works fine in the system but removing it and re-inserting does appear to cause some problems. I believe there is a pullup resistor, or some other mechanism for the extension cable to work correctly. I'm mixed feelings on the issue. Having the card not detect removal correctly could be problematic, but then, a power cycle corrects this issue. However, power cycling isn't a good option. Overall, it's a workable solution, but being as it was designed for car automotive use, I can see the drawbacks based on the above.

Yes, you can plug in the numbers backwards. I've made this mistake on occasion working with analog sensors and couldn't figure out why I was getting unintuitive results. You should be able to use the linearize to set the count (I'm unsure exactly how the rounding happens) so from an analog reading (Not distance but actual input count) of 1000-1300 is one box, 2000-2300 is two boxes, etc.

Back track your logic from the coil you want to set. Look at the preceding statement, does it have a rung that sets it's status. Work backward from there to check the logic. Also, if you're working online while doing this. Make sure the PLC has the current program you're reading from loaded. The software and PLC do allow you to have different programs active and viewed in visilogic but the operands all update as if there is no difference.

I would use a drum (personally I prefer drums for repetitive, sequential tasks over timers but timers work fine as well), to trigger two memory bits, one to read the start count, one to read the end count both into MI. Then do the maths every 60 seconds, or 15 seconds, depending on the update interval.

I was planning on it. Then the recent fiasco came out with the Windows 10 auto updates being completely automatic and required which then fed into a recent driver update breaking people's video card drivers and functionality. I've held off on the upgrade at this point until they resolve that out better.

Unfortunately, all my programs are larger than the allowed size limit. I'd be glad to email it if you were still interested. I am by no means and expert, so I'm sure I do something yet that are not considered standard.

Haven't look at the program yet. I will later today. Some general tips. 1) Never trust the software to work right. (Sorry, see point 2) 2) Your emergency stop should be a hardwired stop to completely cut power to the system, never software. In the US, and I believe most European countries as well a software emergency stop is not acceptable under government regulation because software can lock up and not respond correctly. *Edit* I attached how I would organize your ladder logic to make it easier to follow. I did not change the logic of the program to this point A couple of things that will help a lot. 1) Try to get out of the software mindset and think in hardware terms. Input on the left, output on the right of the ladder (Not required but useful). It will help you immensely when building the logic ladders (If you use that route). 2) Make sure you really understand how the program scan cycle works, keep in mind if you use other PLCs it may be different. Unitronics follows this basic process each scan. Read physical inputs and map to memory Run the ladder logic. Scans left to right, top to bottom. Write physical outputs Updates HMI Communications 3) Something else that may help you is using subroutines to block off your logic into more manageable chunks. I usually run a digital input subroutine, an analog input subroutine, a digital output subroutine, and multiple subroutines for different logic sets. Purely a personal preference though. If you'd like I can provide an example of how I do this. As for your program requirements hardware wise you need at least the following Motor safety cutoff should be controlled through a hardware relay designed for safety operations that defaults to normally open. Also should allow you to input a digital signal into the PLC to let the program know as well. Minimum 4 analog inputs for the encoders 3 PWM style digital outputs for the frequency encoders (possibly depending on that hardware) A handful of digital inputs for various buttons (assuming remote mount) Hardwired E-Stop for power to the system. Questions for the program Thermal protection for what? You'll need either analog input or digital input depending on the sensor type you use. What states are you attempting to monitor? Why do you need an integer to do it? It may seem easier to use an integer but this is necessarily always the case. conveyor v2.vlp

Do you have a linearize function for the operand? Does the input value change as well or does it always read 5 or 6? Is it possible that the wiring is incorrect?

I believe you want to use the Num to ASCII function block as it allows you to convert a number to an ASCII string with a select format such as decimal, Hex, binary or float. Look in the main Ladder Programming manual, page 161 (PDF page 170)

Using an analog proximity sensor to measure rotation may end up being problematic. You'll need to test that the analog signal is between a range, and then increment a counter based on that condition, then divide that counter by the number of blades * 60 to get RPM. You will need to make sure that there is some sort of "locking" mechanism to prevent the counter from picking up noise on the input signal to prevent counting rotations that never happened. Ideally you only want to catch the peak value when the blade passes under or over the sensor. I think the best way would be look for a drop from the peak output by installing the sensor where the change in signal would be the largest and only detect that change.

Very much mixed results. Using SB 217, 218 to verify 1) If I plug in the extension, with no card, they registers 0,0 2) If I then plug in a card, they registers 1,1 3) Removing the card they stays 1,1 4) Putting the card back in writes continue as intended with 1,1 5) Removing the cable from the PLC, they return to 0,0

Initial Tests Extender seems to function correctly so far, though, may vary based on micro-SD card manufacturer. Cloned firmware without issues, applied the clone to another PLC without issue. Next Step Currently doing some extended testing with logging and trend charts.

Using the store function you do need to verify both values work the same way. At 12ma the valve my be half open/closed but is it open or closed at 20 ma? If you're reading 18 ma, should the valve be more open, or more closed? If they are an inverse of each other you'll need to use the linearize function to get the right output, if it's direct, then STORE works fine.

If you have to deal with fluctuations from temperature affecting the system then PID may be the way to go. Fairly easy to work with the hardest part is fine tuning it for best performance, or at least good enough performance.

Your scan time may have been 3.97 ms and adding the additional functions may have only increased it to 4.04 ms. The resolution on the scan time is only 1 ms.

Depending on your setup PID may be over kill depending on your needs. I just finished a setup like this using an electronic regulator (I use PID but setup works without as well). Here is what I did: 1) Read in from the pressure transmitter and scale the value to an integer using the linearize FB. 2) For output a) For non-PID 1) Store output value into an integer 2) Scale that value to the analog output range for the proportion valve using linearize. Compensating for the difference in reading. I also have several rungs to nudge the output in different directions if I'm high or low. 3) Output to the valve For PID 1) Read the analog input and use the input as the process variable ( I linearize everything to the sensor and output ranges) 2) Use the analog output as the control variable. If you'd like I can send you a copy of the program I'm using on a V570, the interface won't work for you most likely, but the logic should be identical. The only issue is a lot of my initialized variables are specific to my application.

I know some people have been looking for an alternate method of accessing the microSD without opening their cabinets due to environmental and/or hazard conditions. Recently found this: http://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O while researching some options. Planning on picking one up and doing some testing to see if it responds without issues and doesn't affect the SD card reliability and retention.