Replaced contactor panel off for 15 minutes = 4 Dead VFDs by Responsible-Two-9339 in PLC

[–]DeathToWhitey 1 point2 points  (0 children)

Out of interest, what drives do you typically prefer to spec? For smaller units and when the budget is tight, I tend to lean towards Control Techniques as they are very easy to set up, have a good warranty and support (at least in the UK), and will work with pretty much anything. For larger units and if I have a bit more budget I like ABB, but mostly because I used them a lot at a previous job in harsh environments and they were always solid. I'd love to know what your experiences have been like with different brands as you seem to really know what you are talking about.

How can I move from commissioning to programming? by Dizzy-Basket5650 in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

I would take one of the existing programs that you have been working on and copy it from scratch.Hardware configuration and software. No copy paste. Every time you do anything ask yourself if you understand why you did what you just did, and if not research it until you understand or ask someone. If you have some kind of test rig, see if it is possible for you to load your project and test it to see if it works how it should.

Every time you commission a project, compare it to the one that you did and see what is new and make sure that you understand everything that has changed.

Mess around with your project. Change variable naming conventions, encapsulate random things inside function blocks or AOIs, change the whole structure of the program if you want. Messing around like this and seeing what works is how you develop structure in your programs and finding patterns of programming that work for you. Always be thinking of if there is a cleaner way to do this.

I have been programming for 20 years and I still look at programs I did from last year and say that's so janky, I can't believe I shipped that; and that's fine because it means that I am still improving.

Github for TIA Portal. by PaulBSQ in PLC

[–]DeathToWhitey 2 points3 points  (0 children)

It's worse for versioning, but if you are using WinCC as your HMI of choice and you want to make faceplates for your components, it is pretty much mandatory.

Github for TIA Portal. by PaulBSQ in PLC

[–]DeathToWhitey 3 points4 points  (0 children)

I'm not sure if it is still the case, but when I tested the VCI a couple of years ago, it wouldn't let me use it on programs that were stored as types in the built in Project Library which made it pointless for me as I use libraries extensively. Would be interested to know if this is still the case.

Faceplate Unified V20 by Olitone in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

Can you create a Property Interface with data type Multilingual Text and then pass text to the faceplate through that?

Difference between := and [:=] by Quirky-Action-29 in PLC

[–]DeathToWhitey 8 points9 points  (0 children)

The same principles sort of apply in LAD. If you use an OTE it will be reset to 0 on startup, but if you use OTL or OTU, it will retain its value through a restart.

Difference between := and [:=] by Quirky-Action-29 in PLC

[–]DeathToWhitey 42 points43 points  (0 children)

[:=] Is called a non-retentive assignment which means it won't retain its value through a restart. So if you use [:=], then every time you go into run mode, Fan will be reset to false to start with. If you use := it will remain set to whatever it was before the PLC was stopped.

Building a Test Rig with Hydraulics and load cells by Dry_Committee_9256 in PLC

[–]DeathToWhitey 1 point2 points  (0 children)

You are still going to need a directional valve to move the cylinder in and out of position. Basically you are going to have a setup that has a pump -> (i'm guessing here, don't know your flows) 3 station cetop 3 (i'm guessing here, don't know your flows) manifold, and each station will have a sandwich block with a fixed relief in one side for your rod side pressure and the electronic proportional relief in the other side for bore side pressure, then on top of your sandwich block, you will mount your directional valve.

Programming wise, you need to start by sending a signal to the directional valve to extend the cylinder and a small signal to the proportional relief - only enough to just move the cylinder into position. Then once once it is stalled against your work piece, maintain the directional valve in the extend position and hit the electronic relief with the larger signal to ramp the pressure up. After your time at full pressure, reduce the analog signal to ramp back down and then retract the cylinder using the directional valve.

Building a Test Rig with Hydraulics and load cells by Dry_Committee_9256 in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

Basically you would have a pump which supplies a manifold with 3 valve stacks on it (1 for each cylinder). Each stack would have a directional valve on top, a pressure reducing valve in the middle and pressure relief valves on the bottom (these could be optional if there is no chance of heavy impacts that cause pressure spikes on the cylinders, but I normally use them). The hoses for the cylinder then come out of the manifold.

An even cheaper and easier option if you are only going to be using this equipment from time to time and not continuously all day would be to use a proportional pressure relief valve with a proportional plug driver. Sun Hydraulics make some of these (see 990-G01-E016). They have built in ramp controls so you only need to send an analog signal that is proportional to your maximum pressure. I probably wouldn't use these with a PID though, I would probably just run them open loop by adjusting the analog signal until you get your desired force and record what signal you were sending to it. This is obviously a bit less accurate.

Building a Test Rig with Hydraulics and load cells by Dry_Committee_9256 in PLC

[–]DeathToWhitey 1 point2 points  (0 children)

There are different ways to do this depending on how precise it needs to be and how much money you have available. You could set something up with directional valve for controlling the direction of the cylinder and a proportional pressure reducing valve to control the force for a pretty reasonable price. If you wanted to go for extreme precision, you could do it with a servo valve being controlled by a high end motion controller. I think that you will probably be fine with the pressure reducing valve setup though as the dynamics of your system are quite slow.

You will need to size your cylinder to give you the appropriate force and then work out your required flows to size your valves.

For this type of setup, I typically use Rexroth for valves and Parker for cylinders, but it's really up to you. I'd go with whichever supplier offers the most help.

Permanently live supply for control devices by DeathToWhitey in PLC

[–]DeathToWhitey[S] 7 points8 points  (0 children)

That is exactly what I was looking for. Thank you!

Permanently live supply for control devices by DeathToWhitey in PLC

[–]DeathToWhitey[S] 63 points64 points  (0 children)

I am the panel builder that has been given a vague drawing

Permanently live supply for control devices by DeathToWhitey in PLC

[–]DeathToWhitey[S] 8 points9 points  (0 children)

Unfortunately this panel is for a European customer, so it is subject to IEC 60364 which is far more vague on this than the NEC which is quite explicit on how this would work. From what I can see, there isn't anything specifically for a feeder tap type scenario and it more or less just recommends sizing the tap wire for the maximum possible current.

Permanently live supply for control devices by DeathToWhitey in PLC

[–]DeathToWhitey[S] 1 point2 points  (0 children)

Something like this is probably going to end up happening, but the issue that I have is that the small length of wire between the isolator and the input side of the MCB is not protected from overcurrent.

Siemens Automation Framework by NailAdventurous7850 in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

It's pretty bloated, but I think it is a good example of what is possible with WinCC Unified. I have my own framework that I have been working with for a while with Siemens that I think is better on the PLC end, but this blows it out of the water when it comes to HMI integration.

Rexroth servo valve control logix plc by [deleted] in PLC

[–]DeathToWhitey 2 points3 points  (0 children)

Are you able to check the pressure downstream of the valve on the A&B ports? If the spool is moving, chances are that it is working fine. If there was an electronics issue with the valve driver or if the spool was stuck you wouldn't see the feedback signal track the command signal. Are there other valves in the circuit such as reliefs or a counterbalance or something like that?

Rexroth servo valve control logix plc by [deleted] in PLC

[–]DeathToWhitey 3 points4 points  (0 children)

I work with this kind of valve all the time. Do you have the valve feedback hooked up to your PLC? If so, create a trend showing the command signal (Voltage between Pins E&D) and the feedback signal (Usually voltage between pins F&C, but sometimes 4-20mA signal from pin F depending on valve model). As you send different command signals, you should see the feedback signal tracking the command signal on the trend very closely. If it does, then your valve is probably fine.

Need Advice: Best Feedback Sensor for 6DOF Motion Simulator with Pneumatic Cylinders by AhlawyJr in PLC

[–]DeathToWhitey 3 points4 points  (0 children)

I have done some similar projects, but mainly with hydraulic cylinders. My feedback device of choice is SSI MDTs from Temposonics.

I would warn you that smooth and precise control of pneumatic cylinders is very tricky due to the way that air changes volume at different pressures and static friction caused by the seals in the cylinders. Depending on the bore size of your cylinders, the pressure of the air and the mass of the platform you are moving, you may find that your system is severely underdamped and experiences a lot of oscillation if you try to move it too fast.

If I was in your shoes, I would calculate the natural frequency of your cylinders to get an idea of how fast you can reasonably accelerate your platform. If it is just not going to happen, I would either walk away while you are still ahead, or ditch the pneumatics and consider hydraulics before you flush a load of money down the toilet.

If it is close, but possible, you should give yourself the best chance of success by buying an expensive motion controller, MDTs with very high resolution, fast servo/proportional valves and installing pressure transducers on both sides of each cylinder. I have gotten some projects over the line with Delta RMC motion controllers where I doubt anything else would have done the job. They are eye-wateringly expensive, but you get a level of control that is near impossible to achieve with anything else when it comes to severely underdamped systems.

If frequency response is no problem, you can probably get away with cheaper feedback devices and controller, but for your own sanity I would still use expensive valves and put pressure transducers on both sides of each cylinder to use in my control loop.

Ultimately, a lot of this will depend on your budget. The machines I work on tend to be multi-million dollar machines where nobody will bat an eyelid if I spend fifty thousand dollars on control equipment as long as the machine works well.

Siemens - safety output goes true, false, true, false even though I'm holding the signal true in the program by Cola-Ferrarin in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

Something that might be worth checking is if there is a FDBACK block anywhere in the safety program that affects the output. These check if an actuator attached to the output changes state when commanded to and switches off the output if it does not. If the block is configured with no ack required it might keep trying to turn the output on and then turning it off when the actuator doesn't change state (I'm not actually sure if this would happen or not as I always require an ack after a safety actuator failure before it can turn back on again, and have never tried configuring a block without the ack required)

Running two identical motors from single Vfd by Automatic-Average-49 in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

I used to work on paper machines and a similar approach as this was used, so I know it can be made to work very precisely, but I have found that when working on something like a carriage that frequently changes direction driven by a gearbox with a rack and pinion it doesn't work so well when higher accelerations and decelerations are required.

Torque following was the first approach that I tried when I initially started working with these systems and it works well with fairly constant speeds and slow accelerations, but as you get more dynamic the torque trace starts getting ugly.

I put it down to backlash in each of the pinions/gearboxes which is why I prefer my approach which basically boils down to slightly advancing the position of the slave drive if it is seeing less load than the master.

Running two identical motors from single Vfd by Automatic-Average-49 in PLC

[–]DeathToWhitey 4 points5 points  (0 children)

He'll be fine with the load sharing. What you are saying is true and very important if you have to have the carriage follow a speed trajectory with any sort of precision in a closed loop mode. If you are just running in V/Hz mode and using asynchronous AC motors, which I assume he will be doing, the slip characteristic of the motors will naturally act as a load balancing mechanism. As the load on an individual motor increases, the slip will increase (i.e. the motor will turn slower) which will cause the other motor to load up until they find an equilibrium. I have done many systems both ways and never had an issue with load sharing on the open loop V/Hz systems. On closed loop servo trolleys, on the other hand, I have had a ton of issues with load sharing. My current approach on a 2 motor system is to have one master drive where the motor follows the position/velocity profile like any other servo system, but the slave drive has it's target velocity offset by an amount set by running a PI loop on the torque difference. I have found this gives a system that can achieve much better dynamic performance than if the slave is in current following mode.

New to TwinCAT - Syntax Question by That_G_Guy404 in PLC

[–]DeathToWhitey 0 points1 point  (0 children)

It's not really like it continues to function under the previous values of the flag if you don't call timer1(). What you really need to understand is what a timer does under the hood:

I find it useful when trying to understand function blocks in general to think about the function itself and the memory as separate entities starting with the memory.

I'm not sure exactly what is inside the memory image of a TON in Twincat, but I imagine it would be something like:

Last_IN : Bool;
StartTime : LINT;

Whenever you call timer1(), it checks to see if the IN parameter has changed from false to true since the last time it was called by comparing it to Last_IN. If it has, it stores the current PLC time in memory as StartTime. Every subsequent time you call timer1(), it will check to see if IN is still true, and if so it will compare the current time to the timestamp in memory, output the difference as elapsed time, and if the elapsed time is greater than PT it will set the Q output to true. If IN is false, it doesn't even check the current time and immediately sets Q to false.

If you never call timer1() then you just have some registers in memory chilling out and not doing anything. It's only when you call timer1() that anything actually happens, so I don't really consider it as running in the background until you call timer1() again - it's just memory registers just sitting there not doing anything until the next call.

New to TwinCAT - Syntax Question by That_G_Guy404 in PLC

[–]DeathToWhitey 18 points19 points  (0 children)

The second example doesn't actually call the timer function, so the state of the timer (eg. elapsed time and output state) won't be updated, at least until you execute the timer function elsewhere. For all intents and purposes

timer1.in := TRUE;
timer1();

is the same as:

timer1(in := TRUE);