MikeSmith

I'm interested, I will send you a message.

Hi Conor, -When you say "trigger" do you mean the PID block is in a routine that only gets called every X seconds. -Is it PID or PIDE? -Can you please give me the configuration parameters of the block? -[time constant estimate] If you hand the combustion chamber at full power from minimum to maximum PV.. how long would it take? -Have you checked the tuning of the P,I,D parameters by using something like Zeigler-Nichols or some other tuning procedure? Thanks, Mike

Your scada package probably wont care about the name your processor calls itself, rather the IP address you give it. If any name is important it's the alias you give the processor in the scada configuration which doesn't have to be the same as the processors project name (but call them the same anyway).

Safety and security are the same word in a lot of european languages... and québécois in this case.

Is the PLC output going logicly 0 and the electronics are not shutting off? 1/ Check wiring, particularly pull up/down resistors if needed Is the output of the PIDE staying high when you hit high temperatures? 1/ Check tuning 2/ Try enabling PIDE block with PV = SP for the first scan it's enabled (just use SEL blocks to put zeros in for the first scan it's enabled).. it stops the PIDE overshooting due to the starting conditions (PIDE does this, PID doesn't due to different algorithms)

No problem if you can cycle the contactors quick enough so that the temperature doesn't change too much just by switching off-on-off. Think of the CV output of the PIDE as the percentage of time the contactor should be closed.. then either use some logic or a specialty card to cycle the contactor to realise this percentage. eg. CV = 0.6 means (picking 10 seconds just for example) a 10 second cycle with the contactor closed for 6 seconds Further reading: http://en.wikipedia.org/wiki/Pulse-width_modulation

I've had a reasonable look into it.. the answer isn't as simple as language alone. It also has a fair bit to do with what you're programming. LAD might be faster in some respects but mostly people don't use conditional execution with it (jumps, ends etc). When your program has a significant amount of conditional execution (state machines, different code executing depending on what's happening) then ST starts to look really good because things like the CASE construct limit unnecessarily executing logic. I wrote a few test programs where ST ended up faster than LAD to do the same thing. SFC is slower and more memory hungry comparatively but it does give you a lot for free as it removes a lot of the effort required to build/modify state machines. It depends how much performance you need.. I've seen it quite happily run high speed motion applications. For heavy maths, I would suggest ST for your own sanity.. it's much nicer to write maths in especially if you're working with cases, loops and arrays.

Salut, I'm not following 100% what you're proposing, do you wish to replace the potentiometer with 1/ An incremental encoder wired to an encoder card in the plc (1746-HSCE at http://www.ab.com/en/epub/catalogs/12762/2...4063/tab6.html) 2/ An absolute encoder (resolver) wired to an encoder card in the plc (http://www.amci.com/plc-modules/plcmodules-slc500-resolver-interface.asp) 3/ Networked encoder with digital communication back to the PLC (eg. http://www.amci.com/rotary-encoders/absolu...ary-encoder.asp or http://www.amci.com/rotary-encoders/absolu...ry-encoder.asp) 4/ Networked encoder card with digital communication back to the PLC (http://www.ab.com/en/epub/catalogs/12762/2181376/104830/2416243/2877322/tab8.html) 5/ Motion controller with digital communication back to the PLC. 6/ Motion card in the PLC (1746HSRV at (http://www.ab.com/en/epub/catalogs/12762/2181376/2416247/1239758/2554063/tab6.html)

For the Rockwell products try http://www.rockwellautomation.com/distributor/uscanada.html Make sure they include the necessary MSSQL licences for the database. Oh, also, one downside of Metrics is that (when i last touched it) it didn't have the ability to change records after (and definitely not while) they had happened. If you need this, ask for a .net web application to do it, there's a few versions floating around Rockwell (one of which I wrote). Also, I'm thinking ahead a little bit here but keep it in the back of your mind, I would suggest not (from painful experience) to embed ActiveX's to either report or talk to the database in any HMI. the reason is that single threaded HMI/SCADA's hang while the database either replies or times out (the HMI freezes if the database is not accessible for the time-out period of the database).

I think you could do it with VB or a programming language. FTMetrics only uses 2-3 tables and pretty simple logic, you should be able to implement the same sort of thing technically (no claims made by me to the legality of this) The quickest(/dirtiest) way would be using MS Excel, get the data from the PLC via RSLinx and DDE (really quick and easy) and then insert sets of these values to a table in MS SQL. Then use a bit of T-SQL to format, compress, present the data etc. Do your reports in SQL Reporting Services. I won't even pretend to guarantee the reliability of building on top of Excel but you should be able to get something like the above out in about a week or two if you know all the products involved pretty well.

Hi, This application is very similar to some FTMetrics jobs I've done, you may wish to have a look at that. Be careful with the amount of traffic going over the network though, it's quite easy to overload with any data logging. ~Mike

G'day, The .net framework (http://en.wikipedia.org/wiki/.NET_Framework) is a common set of libraries that .net languages can all use and a runtime environment that once a .net application is compiled it can run on. >It is the new way to program in C? hmmm... the .net framework is not restricted to one language (vb.net and c# both use the same framework).. but yeah, if you like, c# is an evolution of C/C++ >- It is possible to communicate with plc for get some data (thru serial or ethernet). Yeah, to save a lot of hassle, build yourself something with an OPC client in it with source from here http://www.opcconnect.com/source.php > Do I need driver or soft package? Yeah, don't try and build your own drivers, get an OPC server like RSLinx or Kepware.. >I know VB is more userfriendly but I earing C++ is more powerfull. I don't like to be too subjective on forums so I'll limit myself to this: VB is the devil. The new languages do take a little learning but you can do amazing things quickly... especially by taking the tutorials/labs/videos on msdn. ~Mike

Staying with one vendor does have a huge advantage in holding vendors accountable and getting support when things inevitably go wrong. RSView32 has a web server (http://www.rockwellautomation.com/rockwellsoftware/performance/view32/webserver.html) or if you are thinking of converting your install and project to RSView SE there's a cooler web interface to it (http://www.rockwellautomation.com/rockwellsoftware/performance/viewpoint/).

Ok, in sercos you want to configure the axis as "position servo" rather than velocity if you want it to maintain position. Velocity servo disables the position loop.

Without getting too into too much maths (http://en.wikipedia.org/wiki/Digital_filter), the simplest way to implement a filter is to average the last N samples... so you do something like this... On start-up or reset: initialise the array so that every element is either zero (will mean that the system ramps up from zero to the actual feedback value) or the current feedback value (no ramp time but if you have a bad value on initialisation it can upset the system a bit). On IO update or periodically: move every element in the array down one except the last element move the current feedback value into the first element of the array average the elements of the array (sum of the samples divided by the number of samples) and store the result as the filtered signal value somewhere. You may wish to consider what this dip in the signal actually is though, normally interferance is not a 10 second thing.. seems curious.

Hi Rick, What motion card and drive do you have? To get these basic functions all you should need are the following instructuions (at first I'd be tempted to only have these instructions): MAH(Home), MSO (Servo action on), MSF (Servo action off), MAM (Move), MAJ (Jog), MAS (Stop) and MAFR (Fault reset) which are explained here: http://literature.rockwellautomation.com/i...rm007_-en-p.pdf I'd be tempted to unschedule/inhibit/remove all other motion code and write your own at first. Also have a look at the 'motion direct commands' in the online help to test out motion functions without writing a line of plc code. Cheers, Mike

I haven't seen add-on certifications with automation sought after much but that may just have been me. The certifications I've seen though that sometimes differenciate people are Microsoft certs if you're dealing with MES/MIS systems or Cisco networking (CCNA) if there's a large ethernet component to the job you're chasing. These can be very role specific though, I doubt I would get these just to be generically more employable.

You can use timers if you like but you may also want to have a look at the two 20 kHz high-speed PTO/PWM outputs (on MLX1100 controllers with DC outputs). Also a caution, make sure that the rate you're cycling the valves is within what the valve is meant to do or things might become ill behaved (wear out valves, valves not fully opening or closing etc).

Thanks :) I'm not aware of a packaged motion code offering from RA but it might pay to ask them because it was a reasonably popular trade show demonstration and a standard exercise in the advanced motion course for field service and tech support. I did it in the course and it took me about three hours of programming time (after configuring the servos) to get it working nicely. It's a slow rainy day so... Definitions: Lets call the conveyors from left to right Conv1, Conv2, Conv3 and Conv4, the Sensors Sens1 and Sens2 This exapmle is driven from the left conveyor.. you could similarly work everything out off the conveyor on the right if you need to synchronise with whatever is requiring the packages to be spaced. Start-up logic: Clear faults, home if required (Conv4) etc Gear Conv2 to Conv1 Gear Conv3 to Conv1 Gear Conv4 to Conv1 Start up conveyor Conv1 (which starts the others moving) Correction on Conv2 When sensor Sens1 sees something work out the difference between where the package edge is on Conv2 and where it should be to line up with flights on Conv4 assuming it travels at the speed of Conv1. Issue an MAM on Conv2 to move forwards say 50% of that distance (Use the slowest acceleration you can to get the correction moves done within the length of the conveyor (less energy/slip and makes it look like a really effortless and professional job)). Correction on Conv2 When sensor Sens2 sees something work out the difference between where the package edge is on Conv3 and where it should be to line up with flights on Conv4 assuming it travels at the speed of Conv1. Issue an MAM on Conv2 to move forwards 100% of that distance (which will do the other half of the correction move). Cautions: Conveyor length, speed, acceleration, package width are important, make sure it works on paper before you try to build it. If the package is light or slippery then the acceleration you can get away with on the moves is smaller (without doing things like putting a vacuum under a perforated conveyor, dual sided correction conveyor etc) Use registration specific instructions (MAR, MAW) instructions rather than old school "IF Sensor1 THEN MAM(,,,,); END_IF", it will save having to worry about scan time and repeatability. You may have to correct for slip or the changover between conveyors (small issue unless you're chasing mm's). Make usre the flow rates work (you're not pushing in more packages than you have space for on the final conveyor).

G'day, My suggestion is the same as Peter's, it's a pretty standard application and detailed (wth a pretty animation) here: http://www.ab.com/motion/applications/smartbelt_kinetix.html Mike

There's a fair bit of cross over between kinetix and ultra, it's more about business groups within RA than anything product related. Ultra3000 stand alone is nice and easy to use, very simple and cheap software (RA will charge more for a serial cable than that) and quick to configure.

Glad we've got some numbers on the timing now. You're right to be careful with this. I won't comment on the physical side because there's much more familiar motion analyzer users than I but on the cam I think it's going to come down to the course update rate in the L61. There is a limitation with logix when the cam starts getting small relative to the course update, the CPU only puts out trajectories for the drive for times corresponding to the course update i.e. at the next course update the slave should be at position X. Also cams can only initiate at the course update rate. To make things absolutely certain you will have to: -Run small course update times, definitely below 6ms, more like the default of 2ms. This increases the resolution of the trajectory. -Make sure the master lock position (ordinate of the master axis where the cam starts doing something) happens on a course update event. The will start the cam deterministically. -Make sure your cam points all happen on course update events (or that there's a number of cam points between course updates, but this increases processor load.). This will make sure the trajectory is deterministic. Normally you don't have to worry about things like this if the timing is not so tight. Maybe you might also look at an indexing servo (Ultra3000 indexing?) as it would take the heat off the processor and possibly drop the cost/complexity.

Hi Guys, There's been a bit here on the subject already but I've noticed there wasn't anyone who bit on the performance of the Controllogix L61. I can't comment on the performance of other systems but I've spent the last 5 years working with CLX motion. There are a few cycle times for motion in RSLogix5000 due to different tasks running on different processors/asic's: -Scan time of the PLC logic: This controls when a motion instruction can be initiated, usually with flying sheer this is not an issue as you issue a "pending" cam which you can initiate long before the cam needs to do anything and when the axis you're camming off hits a predefined point the cam takes over.. these are very repeatable and accurite and I have programmed flying sheer applications with them. -Course update rate for motion: This is the periodic (and high priority) task that calculates what the axis trajectories should be given the last 255 motion instructions issued against that axis. -Sercos update rate (make it the same as the course update): The rate at which trajectories and command are communicated out to the drive -Loop times in the drive: The actual closed loop calculations to maintain position, this is done in the drive and does not vary with the number of axes.. usually in the region of 128 micro seconds time performance? In terms of processor load the L61 can handle 31 flying sheer slave axes and one master, scanning all the code (including homing, abort code etc) and commanding the axes with 8ms course update (trajectory calculation). The speed you can send this out to your drives depends on what they are.. for a kinetix 6000 this should be half a milisecond per axis minimum but I suggest setting it to the same as the course update rate. Has it worked before? Yeah, flying sheer is a pretty simple motion task and should be no issues on an L61 unless you're getting down to really low (below tens of milliseconds) cycle times for cut initiation. Cheers, Mike