SLC 500 Nx:xx values

Hello,
I am a new member, and am having a issue with an existing SLC 502 program. A Basic module is writing to the SLC program (M1:9.0 to N7:0), else where in the program it is using a EQU N14:12 / Const. I can not figure out how the N14:12 is getting written to. I am sure this is not enough info, but am hoping to get a dialog started.
Thanks

Post your code if you can ( your .RSS file)
Look for move , copy instructions

RTP said:

Hello,
I am a new member, and am having a issue with an existing SLC 502 program. A Basic module is writing to the SLC program (M1:9.0 to N7:0), else where in the program it is using a EQU N14:12 / Const. I can not figure out how the N14:12 is getting written to. I am sure this is not enough info, but am hoping to get a dialog started.
Thanks

Click to expand...

You do know that N14:12 could be a constant i.e. nothing writes to it.

Code

Sorry - What was I thinking ? I tried to upload the file. We'll see if it worked.

I am trying to post the code, that should help in speeding up this thread.

Just change the RSS to zip then upload.

Thanks
I am thankful, and surprised at the speed of the responces, but must log off for the day. I will be back on Thursday, hopefully to continue this dialog.

Circular Logic?

N14:12 is being written to on rung 39. The weird thing is that rung 38 and 39 write to each other-the same values...

I can see that I am cop(ying) N16:1 to N14:1 (length 99), does this mean that N16:1.0 thru N16:33.0 or how does this Word/Bit structue operate. As you can see, this is a bit out of my comfort zone. Also, note on rungs 59 & 73 the code uses N14:24 & N14:41. This information is fantastic.

length of 99 means that N16:1 thru to N16:99 are copied into N14:1 thru to N14:99

OK, I see whats going on with that now, but to cut to the chase, How is the M1:9 info getting to N16? Sorry to be so naive but this program seems to be going the long way around.
Thanks

Clarify, please.

What makes you say that? The only places an M1 file is referenced is on Rungs 32, 34, 75 & 76. There is no N16 file usage related to any instructions on those rungs. What are you seeing in the N16 file you metion?

N16 is a necessary evil. Think of it as a scratchpad data block used to accomplish a function. What the programmer is doing is shifting all the data elements in N14 down by one element every time T4:31 is done. In rung 38 N14:0 copies to N61:1, N14:1 copies to N16:2, etc. In rung 39 the copy reverses but N16:1 copies to N14:1, N16:2 copies to N14:2, etc. When it is all said and done, N14:0 moves to N14:1, N14:1 (the old one) moves to N14:2, etc. N16 isn't intended to be part of the normal logic. It's just working memory.

I don't know anything about how the Basic module uses the M files. Based on what I see it looks like it uses it kind of like dual ported RAM. Outside of that I don't know what the deal is with rung 32. Even then I'm not sure why the same data location would be used.

When you get right down to it the programmer is making up a time based map of what is in the machine. Every 100 msec the contents of N14 are shifted down. N14:12 contains what was in N14:0 1.2 seconds ago.

Keith

The bottom line is that this program recieves a signal via the BASic module in the form of a 1,2,3,or 4. Binary form. If a 1 is sent, then product is transfered via output O:1/4, if a 2 is sent then etc... If a 4 is sent then no output is used. The program works as written, but we are trying to solve a timing issue related to speed of product/data. I am trying to work thru the logic of getting the BASic info to the output card. Having said all that, I do appreciate all the help offered, but havn't yet been able to digest Keith's response. Once I have a understanding of the logic I will have a better chance to solve the timing issue.

Ron-

Your description matches what the code will try and do. However, your issue highlights a basic physical design problem with the system. The item model (N14) is incremented based on time. This works fine if the machine speed can never change. However, if something causes the machine speed to change all the N14 references will be wrong.

We'll use a specific example, the second reject conveyor. In rung 59, N14:24 is compared to 2. The 2, I presume, means the item should be sent to the second reject conveyor. Because the values in N14 are bumped every 100 milliseconds, we assume that an item that was inserted on the conveyor 2.4 seconds ago with a value of 2 is now at the second reject conveyor. If the speed of the conveyor is still the original design speed this is all fine and good. If not, when the value of 2 DOES show up in N14:24 (it will show up there in 2.4 seconds no matter how fast the conveyor is going) it may not correcspond with the desired position of the item on the conveyor, causing a misfeed.

Additionally, it appears that the program detects if an item is in the area of the rejects and only evaluates the item model if an item is detected. It is possible that the item won't set the zone latch until after the item has passed the zone in the model. In this case nothing will happen at all.

Ideally the model would be incremented by something that it more closely tied to physical conveyor travel; something like a prox or encoder. However, this won't help if the item is slipping on the conveyor.

Keith