CanaanP

Well, that trend was taken after we removed the encoder from the first feed roller and built an arm that holds the encoder against the wood, which was located pretty close to the cutter head. There was a spring in the arm mechanism that allow the encoder to float with about 1/4 - 1/2 inch travel. The encoder is set to 960000 counts per aux rev, which the new roller we put on the encoder was a knurled 12" aluminum roller.

Ok, here's my setup: L43 with sercos card, ethernet, 6in/4out combo card. Kinetix 2000 with a 842HR-SJDZ115FWYD (sin/cos encoder), and a MPAI-A3150EM32A (heavy duty electric cylinder). The encoder is mounted to a feed roller on a machine that will accept boards and cut radial arcs into them at specified intervals. The boards are used for stacking pipe. I'm using an MAPC instruction to control the movement of the actuator based on encoder feedback. This has worked great in the shop as I was testing the PLC equipment, without being mounted on the machine itself. This project is a retro-fit of sorts, and I am now on site with all equipment installed. My issue is that as I feed boards through, I never get two that look the same. This is exactly opposite of what PCAM is supposed to do. My only lead is that the slower I run the infeed, the more accurate the system is. At full speed, 60 feet/minute, the arcs are different from each other, they are spaced incorrectly, and no two boards that come out will even be the same. I could understand if it was wrong, but wrong in the same way each time... this is wrong, but randomly. Half of that speed was supposed to be used for boards that will require deeper cuts, so I tried that, but with the same cuts that I was using before, only 3/8" deep. At 30 feet/minute the results were a little better, but far from acceptable to the specifications requested. At 1/4 full speed, 15 feet/minute we got the best results, but still not quite acceptable. I am not sure that I have the proper settings entered for the encoder resolution and conversion constant... My feed roller that the encoder is mounted on has a circumference of 12.89" according to the customer. So I go to Calculate Position Parameters window in the encoder properties of the motion group. I enter in 12.89" for Position Unit Scaling, Per 1 Aux Rev. Then for Position Unit Unwind I enter 150", per 1 Unwind Cycle. When I hit calculate, I get a popup warning that says "Possible truncation error calculating position unwind. Allow Update?" I say yes and it plugs in a drive resolution of 902300, and a conversion constant of 70000. Position unwind is set to 8400000. Ok so to test to see if the measured value from the encoder is accurate, I devised this system: 1. With cutter head retracted and out of the way, I manually jog the feed roller to grab a new board. 2. I make a pencil mark on the side of the board against a piece of the machine frame. 3. I issue MRP command to set encoder to 0.0 4. I then manually jog feed roller again until about 6 or 7 feet of the board has entered the machine. 5. I then make a second mark on the board against the same piece of the machine frame. 6. I take note of the encoder value, then roll the board the rest of the way out. 7. Measure distance between marks on the board and compare to encoder value. Now, at my best trial, the difference was maybe an 1/8" off. But never twice in a row, even when leaving all settings intact. In other words, running a board through this test twice in a row will yield different values between the encoder and actual measurement, and yes - I made new marks the second time and made sure to use them, and not the first ones. I was told that if you are using 70000 as a conversion constant, you can multiply that by the value the encoder claims it traveled, then divide by what it actually traveled and that should be a good value to use as a new conversion constant. Well, I tried this many times, redoing my test after each change. The results were always the same. I may get very close on one run, within an 1/8", but if I run it again without changing anything, I may be 1" off. I contacted rockwell support and explained all of this. All I was told was, email me your project and I will take a look at it. Of course, it was about 4pm est at that time and I'm sure the guy was ready to leave or getting close. So I may not hear anything back until tomorrow afternoon at best. This issue is a deal breaker for this project. We cannot accurately cut arcs into a board repeatedly if our encoder reads different each time. I don't know what to do. Can anyone offer some ray of hope on this issue for me? PLEASE? Thanks for taking the time to read this :)

We had the machine here most of last week, and our vendor sent a motion guru to help us out... he set up this trend, and it shows a board going through with cuts being made. We have determined that the feed chains that tie all the rollers together is what is causing the encoder noise. You can literally count the spikes in this trend and they coincide with sprocket teeth on the feed system. The customer has picked the machine up, and on our recommendation is going to change to either a cog belt system or possibly individual motors on each roller, controlled by a single VFD. I will be headed back out there to Ohio once they have modified the machine and then we'll see what can be done on this project. Thanks everybody for the advice and for listening :) I'll post an update when there is one.

I setup a trend on the encoder actual velocity, with default sampling settings. Here is a screenshot I took of it: I don't know if this is normal or not, but as you can see there is a pretty big spike there, and that occurs randomly about once a second or more (average). Could this be my problem? I tried disconnecting the shield in the encoder cable on the Kinectix 2000 end, but it did not seem to change the trend, so I put it back. This speed is about 5 feet per minute.

The machine is here at my shop now, so I will have all the chances I need to mess with this thing. I will try a trend on the encoder velocity to see how that looks... I'd say the speed was about 30 feet per second in that video, which is low speed for this machine, high speed is at 60 fpm.

You have it right sir... but here's the problem - this PLC and actuator, etc is a retro fit job. Originally we had quoted this hardware when the machine was in design phase, but I think the numbers scared the customer. They built the machine using an alternate method, a physical cam system to push the cutter head arm into place. Here is a quick video I took of the machine in action: http://dl.dropbox.com/u/483701/video-2011-06-24-08-27-15.mp4 I don't know why I didn't think to post that sooner, but there it is. Ahh, I started talking about a problem... the customer built the machine as it is shown in the video, they were happy with it except there was a problem in the shape of the arc, I guess a problem that was inherent with the cam system. That is why they came back to us to do this PLC install. Now, the heart of the problem: while outfitted with the cam system, all boards that came off this machine were slightly wrong - i.e. the shape of the arcs, however they were all the same. The only thing that has changed between then and now is the cam being replaced with an actuator, and encoder added to the roller. Now this is a customer claim, and I was there to take a video but had not gotten into this encoder mess yet so I didn't take careful note of the accuracy of the pieces coming out of the machine. So apparently, there was no slippage involved at all, or if there was, it was identical each time a board ran through the machine. The good news is that the machine is on it's way to my shop now. This means I don't have to drive another 13 hours to get onsite and try to resolve the issues :) I think what you were saying about the cuts being too short may not be entirely true, it's not that they are short or long... it's that they are not the same from one board to another. But now that the machine will be here on my turf, I can run some more material through and take careful measurements and try to spot a pattern. We have also recommended the option to have a roller in direct contact with the board, but the problem there is that the positioning of the roller. If it is before the cutter head, the board will leave the roller and still be in a cutting process, therefore encoder value becomes useless - impossible to PCAM. If the roller is after the cutter head then the board will not reach the encoder until after at least the first one or two cuts should have been made. It can not go on the side of the board because some boards will be run through twice to put arcs in both sides (for in between layers of stacked pipe). Therefore the only solution I can think of is to put the roller directly in front of the cutter head, trying to catch a little bit of the board from the top. This is tricky though, since boards will be different size, and cuts will be of different depths. We surely don't want the cutter head to eat into the roller. When the machine is here, I will analyze that scenario a bit more.

The cutter head approaches from the left side, here's the pic of that: The encoder is on the first feed roller, which is the sprocket roller on the bottom, that was in the pic on the other post. The tension roller on top is spring loaded, and can be adjusted with a jack crank of some type. There is a tension roller above every sprocket roller, and there are about 6 I think, 3 in front of the cutter head and three after with only a few inches in between. The issue with the boards is this, the starting point doesn't really matter too much because I know how to adjust that - putting a different negative value into the MRP instruction. But the distance between the arcs is not consistent, nor is the length of the arcs. Both the length and distance between is obviously related to the encoder because it's all coming from an MAPC instruction. I was told the the actuator can more than handle the force that's being applied and do it with more than enough speed, but now I'm not so sure... I mean our best results are at very low speed - is that because slippage is less or because the actuator has more time to do it's PCAM correctly... I'm unsure. It's very frustrating.

Well that definitely sounds like a good plan, as far as calibrating at very low speed, then top speed, etc. I know that our full speed was 60 feet per minute, and low speed will be at 30 fpm. I slowed it down to 15 fpm during a test and ran two boards back to back and got this result: This is what the roller looks like that moves the board through the machine: Anyway, I'm attaching the program zipped up as well. I don't remember if I explained this in the OP or not, but I'm using a limit that is located a couple of inches back from the cutter head to issue an MRP to the encoder. I'm putting a -2.125 in there as I recall. This is what we came up with after several tries to get the beginning of the first arc to line up with what we put into the cam profile. Anyone looking at this program, keep two things in mind... 1. I intended to refine this quite a bit after I verified the core components working properly, which never happened. 2. This is my first motion project and I'm kinda feeling around in the dark. RaggleTest.zip I'm currently back home in MO, the job is in OH - 13 hour drive from here. I think we are going to see what can be done about adding a roller that rolls directly off the board for using the encoder. But it may be a little bit before I'm back at the machine again. So I definitely appreciate all of the advice I've been given, I just won't be able to implement any of it until I'm back in OH. Thanks again.

I completely agree... it sure doesn't seem like the boards are slipping because the design seems very solid. However, the results are pointing to that... as you said, it should be repeatable regardless of whether it's wrong or right on the encoder.

Ok, I can try that. I have never used tasks before, so I will have to wing it. There aren't that many rungs of logic though, 31 total in three routines. I have not checked the scan time, but what perhaps you are right. One thing I'm curious about though - if I execute a MAPC instruction, doesn't that instruction carry out it's cam profile entirely once it's been commanded? I mean, the PLC isn't checking back with it every scan cycle to tell it to do the next cam point is it? I thought it was like a fire and forget type thing.

I took your advice, this is what I came up with... I setup a timer that starts when the load profile button is pushed, turns out it's more like 4.5 seconds until the trend is complete... I tried to speed that up, but the faster I made it, the more "anomalies" I saw in the trend. Anyway, while the timer is timing, visibility on the trend itself is turned off. I think I may also put something in there that writes the display number to a tag, and also activate that timer whenever the display is loaded, because the weird heart rate monitor effect is also happening anytime you return to that screen.

Hello, I am working with a motion project, and will need to allow the operator to choose between several different cam profiles. I have this working fine, but I would also like to add the ability to add a new profile to the array I have of profiles. Is there a nice friendly way to present this to the operator on the screen? Something that looks similar to the actual cam editor window? If not, then how would you guys recommend handling this? Thanks in advance for any help offered. EDIT: Ok, I realize this was very vague... let me clarify and simply what I am needing help on - maybe then at least 1 out of 50 people that view this post will reply. All I want to do is be able to show a graph on a PV display. On this graph I want to plot values from an array. For each element in this array I have three values, only the first two of which I'm worried about showing. They are both data type REAL. These are values for a CAM profile. Does anyone know if it's possible to chart values from an array?

Thanks, I appreciate your feedback :) It is impossible to show in a screenshot, but when changing profiles there is about a 2 second period where you see part of one profile and part of another on the trend. It's like a heart rate monitor... That is my only peeve about this setup. However, it is accurate data, and the only reason it's there at all is to give the operator a warm and fuzzy feeling about the chosen profile, instead of just looking at a table of numbers.

Ok, so I worded that wrong... my bad :) Here is the logic I used to create trend values... Here is the main PV screen that shows the profile that is selected, and a [cough] visual representation of the cam editor... This screen shows my best efforts to allow the user to create or edit existing profiles by entering values in for x and y then the movement type.

Yes the PV can display jpg easily... but the problem is that this program allows for editing of the profiles via a table entry method, so once the profile is altered the screenshot is no longer accurate. That's why I need to plot the points on a graph and have it refreshed each time the profile is changed. I have been playing with the trending today, and I think I have something close enough to what will work. I created a self repeating infinite timer in my PLC program and on the .dn bit I move the next array points to a tag and trend that. It resets when the selected profile is switched from one to another and the refresh is pretty fast... not a perfect solution - but it appears to be the best that FTVS can do with this stuff.

That's actually the best answer I've heard, IMO. I will try something like that today. Peter, something that I have been trying to make clear this whole time is that I do not need to do any cam editing on the PV. I only want to show the points on a graph... I already have all of the math and code finished to allow switching from one profile to another, or customizing an existing profile, or adding a new profile. This has nothing to do with what I'm asking for... as I said, it's merely to show the points on a graph - nothing else.

That looks pretty cool, but I'm afraid Red Lion is out of the question. It's AB or Magelis for touch screens here...

No worries... I will keep searching though. I already have the system setup where all of the profiles can be edited in FTV, but it is only in a grid view type display... the only element missing was a nice graph that had the values plotted. I'm still refining that screen... if I can't find a way to plot the stuff on a graph by the time the whole project is done, then that's the way it is I guess :)

I understand all that you are saying, and I appreciate the suggestions. However, I think I'm still not getting across here... I do not want to be able to edit the profile from the screen. I already have a setup where they can choose a profile from the list and manually edit the values one at a time. All I want is to plot the points that are in there onto a graph so they can visually see what is setup. Taking a screenshot won't do me any good because after the profile has been modified then the screen shot is no longer accurate. I have an array of 30 elements, a master value and a slave value for each element. This is like XY plot. All I want is to load those values onto a graph on the screen... if the values have been changed, the graph would still be accurate once the changes were saved. EDIT: I should also mention that at this point in the program, the values are not a CAM Profile, this is an array of a UDT I created to mimic a profile, because I have 20 different "recipes" that can be selected, each with an editable profile. Since 5000 doesn't allow editing of profiles, they have to be calculated before it can be used as a motion instruction, I had to make this to allow editing on the array elements. Then, the user selects which profile to use, then that profile is copied to the actual CAM Profile, then calculated, etc. So as far as plotting these points on a graph, it has nothing to do with the cam editor, I only showed that image as an example... what I am asking for is a simple graph that plots XY values, those values need to loaded from an array that I specify. That's all.

This is the cam editor window inside RSLogix 5000. All I want is to provide something that looks remotely close to this... I tried trending but I don't want the graph to move or trend anything, I just want to read the points from my array and show them all at once.... I can't believe this doesn't seem to be possible.

I have a simple project with a panelview plus 1000. I am working with FTVS ME and have three displays. The main display is for the operator to do daily tasks, however the settings display and calibrate display are for supervisor only. I was wondering if there is a way to popup login fields when a user attempts to go to a restricted display? I have never worked with security on these before, and I know very little about it. At this point, I cannot even seem to get a regular login working. I have created an "admin" user, and gave it all security codes. I removed all codes from ananymous except for A. I changed main display to A, and restricted displays to B. I then put a login button on the main display. When attempting to login with admin credentials, a message is shown that says "login of user 'admin' failed, insufficient access rights". Can someone please tell me what I'm missing here? As for the initial thought of automatically popping up a login window when user attempts to go to a restricted display - I would love to be able to do that, but if its required that a user login first, then try to access a display, then so be it... Thanks in advance for any help.

Thank you, I'm not sure what I did... other than go home and get some sleep - but I this morning I removed the admin user from runtime security and in the user groups. I recreated it, exactly the same as I remember doing it yesterday, tested and it worked. That's disturbing to me, but I'm going to just run with it for now :)

Not sure why I haven't been able to find anything on this, unless its impossible...but it seems like it should be possible. I would like have a row of "buttons" on the bottom of my screen for navigation between displays. I have an up image and a down image. Shouldn't I be able to have a goto display button, then the up image, then the down image all in a group, then set the visibility of the up and down images based on an expression evaluating the active display?

If anyone can recommend a way to solve this I would be very appreciative: I am working on a project for an automated double band saw machine. We will use an ultrasonic scanner to measure the height of a board before it comes to the blades. There are two blades, each one is on a ball screw motor that can adjust the height of the blade. The operator console will have the ability to program three preset measurements. The operator chooses a preferred preset. When each piece is scanned, the plc must "decide" which is the most efficient way to position the blades to get any combination of the preset measurements. The first blade must make the lowest cut, the second makes the other. The customer expects the PLC to contain truth tables that control the blade settings based on the incoming measurement. There is a tolerance of +/- 1mm. The operator can also specify the saw kerf, which is the material lost with each cut due to the thickness of the blade. All measurements are in mm. I have never done this before, but I was pretty certain this can all be done "on the fly" instead of having to make tables for this. Here is an example of a scenario: Presets are 58, 70, and 83 Incoming board is 142.4, preferred preset is 83. First blade should move to make a 58 mm cut, second blade moves out of the way, the remainder should be 83mm. In this example, which was provided by the customer, I am able to get my program to work fine. After taking into account a 2.4 mm kerf, I get an 83mm piece and 57, which is within tolerance. However, I cannot get this example to perform correctly in my program: Incoming board is 202.8, preferred preset is 83. This should yield two 58mm pieces and one 83mm piece. My program says that there will be two 83mm pieces with 32mm of waste. Obviously they would rather have only 1 83mm piece and two 58mm pieces so that those pieces could be used on another job or something, instead of throwing away 32mm of material. But I cannot seem to figure out how to make this work. I am attaching my 5000 file for anyone to look at. Any advice would be greatly appreciated, thanks! EDIT: I forgot to mention, this is of course a very rough test program that I made so I can test things out. I have this project running on the 5000 emulator program, and a test HMI screen in FT VS. I do not have the scanner hooked up obviously, so I am just directly inputting a measurement into the measured_height tag, then hitting a button on the screen that toggles the scan_process.start tag to get my results. I also wanted to mention that the problem in the second example I provided, where my program fails to come up with the desired results, is occurring on rung 5 of the test routine. This is because I'm looking to match up the remaining material with the largest of the presets to create a second piece. But I'm not sure how else I could handle this to have as little waste as possible. Thailand_Test.ACD

I can see using a minimum waste figure to help this program, but I really didn't want to do recipes... there is actually a 4th preset that I have yet to put in. They wanted it to be there, but not yet activated, then they also wanted the ability to go in later and add new tables... as I said - I would rather not use tables and would like to just do it with math on the fly if possible... I'm very close, just not quite there.