Michael Lloyd

You can drag and drop and AOI from one program to another. I have a "base program" that has things like IO cards, tags, UDT's, AOI's, etc set up and I either start with that, rename it, and program it or in the case of adding an AOI or UDT I just open up a second instance and drag it from one to the other.    I can right click the Add-On Instruction folder and see Export and Import. Not sure why you can't see that with your software unless there's a licensing issue. 

Is there a report button that will let the moderators know a moron has splattered his hacking nonsense on the site? There have been a lot of posts that don't make sense on the site lately. If we can help get rid of them please let us know how.

Well at least it wasn't in plain site or anything. Thanks for pointing that out. I used it this morning

Truth be known, I use an index in one routine and it's little more than a loop that references a single value that's indexed +1 on every loop, otherwise I can't stand troubleshooting indexed addresses (on anyones platform)

In the Ham radio community there is a need for time synchronization for weak signal communication (FT-8 and JS8Call). The link below will take you to a very popular option for a networked time NTP server. It lives on a network, uses the global GPS satellite system to set the time, and at $425.36 the price is reasonable. http://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=272

Very handy! 

Pretty much.   I maybe putting too much into using indirect addressing and it’s been so long since I’ve needed to do that I’m probably making it seem simpler than it is, or not. FGEN can be very handy. 

I couldn't figure out how to format the post above this... the point of it was to show you what Xn and Yn is about If n = 0 Xn = X0 and Yn = Y0 also Xn+1 = X1 and Yn+1 = Y1 N is the index pointer. Ie it points to the variable. In your case your going to need two 10 point floating point arrays, one for deg C and one for kPA. Like F0, F1, F2 ... F9 for X and F10, F11, F12,... F19 for Y which means your going to need to index two pointers, one starting at 0 and one starting at 10.  

        degC          kPa X0 0.01 Y0 0.6117 X1    10 Y1 1.2281 X2    20 Y2 2.3392 30 4.2469 40 7.3851 50 12.352 60 19.947 70 31.202 80 47.416 90 70.183

Not sure about the PLC5, but with a SLC you might be able to use the limit (LIM) and Compute (CPT) instructions with this: When X[n] < In £ X[n+1], calculate Out = ((Y[n+1]-Yn)/ (X[n+1]-Xn))*(In-Xn)+Yn Where LIM is constrained by this: X[n] < In £ X[n+1] and each CPT would be based in this except you would use indirect addressing and index the pointer with logic similar to what is below ((Y[n+1]-Yn)/ (X[n+1]-Xn))*(In-Xn)+Yn If you're real good you could initiate something like what's in the attached PDF to loop through and index the pointer so that you only need one LIM and Compute rung inside the LBL called loop in the attached PDF. Logic explanation to follow. Rung 0 - Clear the Index Rung 1  - Start the loop routine (in this case it's working on one of many Analog arrays, calculating alarms, etc Rung 2 - Increment the index Rung 4 - Test if the index has max'd out, if not go back to loop and if it is go back to Run 0  Again, CLX logix not SLC logic but it could be adapted. RSLogix 5000 Report(s).pdf

Check out the red text below. Maybe that will give you an idea of what you need to do. Indirect addressing might help. BTW - this is a Control Logix function block, not something in the SLC. It's basically calculating the slope of a line segment based on each segment delineated by the X/Y coordinates given in your table, not a line. Function Generator (FGEN) The FGEN instruction converts an input based on a piece-wise linear function. Available Languages Ladder Diagram This instruction is not available in ladder diagram logic. Function Block   Structured Text FGEN(FGEN_tag,X1,Y1,X2,Y2); Operands Function Block Operand Type Format Description FGEN tag FUNCTION_GENERATOR structure FGEN structure X1 REAL array X-axis array, table one. Combine with the Y-axis array, table one to define the points of the first piece-wise linear curve. Valid = any float Y1 REAL array Y-axis array, table one. Combine with the X-axis array, table one to define the points of the first piece-wise linear curve. Valid = any float X2 REAL array (optional) X-axis array, table two. Combine with the Y-axis array, table two to define the points of the second piece-wise linear curve. Valid = any float Y2 REAL array (optional) Y-axis array, table two. Combine with the X-axis array, table two to define the points of the second piece-wise linear curve. Valid = any float Structured Text The operands are the same as for the Function Block Diagram FGEN instruction. FUNCTION_GENERATOR Structure Input Parameter Data Type Description EnableIn BOOL Function Block: Enable input. If cleared, the instruction does not execute and outputs are not updated. Default is set. Structured Text: No effect. The instruction executes. In REAL The analog signal input to the instruction. Valid = any float Default = 0.0 XY1Size DINT Number of points in the piece-wise linear curve to use from table one. If the value is less than one and Select is cleared, the instruction sets the appropriate bit in Status and the output is not changed. Valid = 1 to (smallest of X1 and Y1 array sizes) Default = 1 XY2Size DINT Number of points in the piece-wise linear curve to use from table two. If the value is less than one and Select is set, the instruction sets the appropriate bit in Status and the output is not changed. Valid = 0 to (smallest of X2 and Y2 array sizes) Default = 0 Select BOOL This input determines which table to use. When cleared, the instruction uses table one; when set, the instruction uses table two. Default is cleared. Output Parameter Data Type Description EnableOut BOOL Enable output. Out REAL Output of the instruction. Arithmetic status flags are set for this output. Status DINT Status of the function block. InstructFault (Status.0) BOOL Instruction generated a fault. XY1SizeInv (Status.1) BOOL Size of table 1 is invalid or not compatible with the array size. XY2SizeInv (Status.2) BOOL Size of table 2 is invalid or not compatible with the array size. XisOutofOrder (Status.3) BOOL The X parameters are not sorted. Description The following illustration shows how the FGEN instruction converts a twelve-segment curve.   The X-axis parameters must follow the relationship: X[1] < X[2] < X[3] < ... < X[XY<n>Size], where XY<n>Size > 1 and is a number of points in the piece-wise linear curve and where n is 1 or 2 for the table selected. You must create sorted X-axis elements in the X arrays. The Select input determines which table to use for the instruction. When the instruction is executing on one table, you can modify the values in the other table. Change the state of Select to execute with the other table. Before calculating Out, the X axis parameters are scanned. If they are not sorted in ascending order, the appropriate bit in Status is set and Out remains unchanged. Also, if XY1Size or XY2Size is invalid, the instruction sets the appropriate bit in Status and leaves Out unchanged. The instruction uses this algorithm to calculate Out based on In: When In £ X[1], set Out = Y[1] When In > X[XY<n>Size], set Out = Y[XY<n>Size] When X[n] < In £ X[n+1], calculate Out = ((Y[n+1]-Yn)/ (X[n+1]-Xn))*(In-Xn)+Yn Arithmetic Status Flags Arithmetic status flags are set for the Out output. Fault Conditions None Execution Condition Function Block Action Structured Text Action prescan No action taken. No action taken. instruction first scan No action taken. No action taken. instruction first run No action taken. No action taken. EnableIn is cleared EnableOut is cleared, the instruction does nothing, and the outputs are not updated. N/A EnableIn is set The instruction executes. EnableOut is set. EnableIn is always set. The instruction executes. postscan No action taken. No action taken. Example In this example, the FGEN instruction characterizes a flow signal which is then totalized using a TOT instruction. The FGEN_01X1 and FGEN_01Y1 arrays are REAL arrays of 10 elements each to support up to a 9 segment curve. You can use arrays of any size to support a curve of any desired number of segments. Function Block   Structured Text FGEN_01.IN := Local:1:I.Ch0Data; FGEN(FGEN_01,FGEN_01x1,FGEN_01Y1); FlowTotal.In := FGEN_01.Out; TOT(FlowTotal);

Now is a good time for the FGEN block, that doesn't exist in the SLC

I just tried a number of curve fits here: https://mycurvefit.com/  and (a) I don't think it's linear based on the data I got in a spreadsheet (b) surely they gave you a formula? Spreadsheet output below. M is for the formula Y=mX+B (equation of a straight line) and I assumed B = 0 Slope is the result of the Slope of a line equation  where Slope = (Y2-Y1) / (X2-X1). There's nothing linear about either result : Y X Slope M 0.01 0.6117   0.016348 10 1.2281 16.20701 8.142659 20 2.3392 9.00009 8.549932 30 4.2469 5.241914 7.063976 40 7.3851 3.18654 5.416311 50 12.352 2.013328 4.047927 60 19.947 1.316656 3.007971 70 31.202 0.888494 2.243446 80 47.416 0.616751 1.687194 90 70.813 0.427405 1.270953

Caveat- Long time Control Logix programmer. I have a strong bias to Logix. Every now and then I have to suffer through writing a SLC program (or worse troubleshoot a SLC program run through the converter grinder disaster that Rockwell supplies), on really bad days I need to get into a ROC or other device :) <-- somewhat tongue in cheek because it really doesn't matter, but I do like the CLX box for it's openness and simplicity  I'm trying to give this "thing" (CCW) a chance because I like the hardware. I think it has a lot of potential, pricing is good, and it seems like the hardware is robust. I've, so far, been able to overcome perceived roadblocks (learning new software is never fun for me, especially if the software sucks lol). One major roadblock is testing my patience this morning. I want to do something that's very simple to do in RSLogix. I want to export my tagname database, modify the comments, then import it. With Logix, unless they fixed it, for the tag to show up in the CSV file there has to be something in the comment field. I have a program template that I have pre-documented with Spare or x or whatever works to make it show up in the Excel CSV. Then I copy and paste from an IO sheet to the exported CSV and then import it. That's how it works for me in Logix.    CCW- It seems simple enough, right click the PLC in the tree, click Export, select variables. I documented the IO in the Global Variables comment column and saved the program so I assumed that exporting variables would give me a list of those comments. Nope. Global variables don't export. At least I haven't found a way to make it work. I really want to like this thing but the simplest things are about as pleasant to do as having a root canal or are simply non-existent. I'm hopeful that there is some "clever trick" out there that will make something simple like a tag export work

Ditto. I've had a Micro820 on the bench since it first came out. The programming software quickly killed any interest in using it. The plan was to replace the Micrologix that we use on very small projects (something with a small IO count. Like 2 DI, 3 DO, and an AI). There's a Compact Logix with onboard IO that fills that need but it's about 4x the cost of the Micro.  Fast forward a number of years and I saw that they (Rockwell) make reference to Logix 5000, AOI's, etc in their literature. I thought that they had fixed their software so I started investigating it for replacing small IO count projects that the area I work in now uses a Fisher ROC for (same company but I'm now in the Four Corners area instead of the Gulf Coast of TX, for now). To do that I need to train a few techs on the use of LOGIX 5000 software and CLX PLC's. I had hoped, based on advertising, that the CCW software had been updated. It hasn't. I've spent almost a week bugging my local reps (super helpful group of guys), wasting my time with tech support, and trying to make the 800 series fit into a place that it's simply not going to be useful for.  

Tech support replied to my email. This supports why I don't think the Micro 800 will ever be anything that is useful. Simply put, I read this as we don't make it easy to use just in case someone would actually use it:. People are too stupid to not duplicate a variable (at least I can spell variable). This is my reply to them.  Thanks for the reply. I’m sorry but your explanation makes no sense. I can document the IO in a SLC, Compact Logix, and Control Logix PLC with import / export and Excel. Programmers are smart enough not to duplicate a variable. Even if we duplicated a variable the software warns the programmer about his or her error. If you want people to buy this thing make the software useful. As it stands now there’s no real reason to use The Micro 800 due to it’s poor programming interface. -------------------------------------------------------- I know I am wasting my time but it irks me to no end that they are letting a viable piece of hardware suffer from a useless interface. Maybe it sells well for tech schools but no integrator in their right mind would use this thing on purpose. 

Yep. You can move floats but most people pack bits into integers and move those as integers and values are moved as integers (2 integers for a floating point value)

I found that blog article when I searched earlier today. I've already tried his method and it doesn't export Global Variables. I've about come to the conclusion that I will be better served to train my guys on Control Logix and quit playing in the kiddy pool. 

I’m typing this on my phone so typos by Apple Think of the radio system as a wired system except you need the address for each end (gross oversimplification but the takeaway should be that radio comm is not harder, just slightly different) Your “crosstown” question could be a simple matter of the PLC you’re looking at is the slave and the polling master is across town reading the N registers that the Mov’s are writing to.

I break my program into small routines. I assume that it depends on what the PLC is controlling but I only worked in one business. We have pumps, valves, scaled analogs, alarms, shutdowns... things like that. Each pump gets it's own routine, each valve gets it's on routine. If a tech needs to know why a certain pump doesn't run, all he has to do is check the routine. It could be that the starter tripped. He or she will see that in the failed to start trip. Maybe it's low suction pressure or the valves failed to sequence properly, in which case the tech would then go to the valve routine. You can do the one massive routine program but you're throwing away one of the good parts of the CLX design (and SLC for that matter).   PS - what platform are you using?

I think they missed an opportunity by not making the software look more like Logix.  The fact that the tutorial for creating a TON instruction is 24 pages long says a lot

This might be helpful. 24 page tutorial to show how to use a timer  https://www.brightonk12.com/cms/lib/MI02209968/Centricity/Domain/517/Tutorial%2002%20PLC.pdf

After loading 12 and running it I re-read the salesman's email. He said 12 is coming out this fall. I hope that was a typo. I just sent him this (including his part): My salesman never has to wonder what I think.  They have a $450 upgraded that might have some value but not even Fabreeze can make fresh poo smell good so we'll see. It's a shame they rolled out new hardware with such a pile of crap for software. Software sells their product. Even worse, they just keep rolling the same garbage out.

I finally got the software loaded (Version 12). I see where you are coming from. This is a perfect example of why I never adopted their little brick. They make something as simple as a timer into a kludgy mess. If I had spare time I'd be doing something better than working inside of their ratty software. Supposedly they are going to make things better with Rev 14.

I am absolutely not a fan of the migration tool. Logix is such an outstanding platform and migration just squanders the flexibility of the platform away. You end up with all kinds of "useless trash" in what could otherwise be a clean and easy to troubleshoot program.  I work in oil and gas so we have it a little simpler than other industries. DI, SO, AI, AO and some communication (Modbus) every now and then. I've used Message blocks to transfer bits from PLC to PLC of over the WAN (think 100's of square miles or more not building). With that said, I'd rather develop the program based on the needs of the process. That way I know what's "in the box". I start with an IO list, followed by a transmitter list, then alarm and shutdown list, then the cause and effect (all in one Excel sheet). Again, what we do in the industry that I work in is not hard (if you know the process).  DITTO!