Can you recommend the proper direction on SLC500

[OkiePC]

Post your code, so we can continue working on the same version.

I didn't include the original in my example, and there are many things that can be done quite easily to clean it up, make it shorter, and even do away with the dummy steps to give the required off time between commands.

The error with the indirect address means that a pointer used in an indirect address ([N7:0] in my example) is greater than the highest element number of the file.

I am not sure what you meant about moving from B3:7/15 to B3:8/1...lost me there...

Since you have 22 macros, I may write up another example to accommodate all of them.

What version of RSLinx do you have? If you have a licensed version, we can use Microsoft Excel as a temporary interface to make it much easier to document the required data for the macros, and then send the data directly to your PLC.

Even with RSLinx Lite (which does not support DDE/OPC), we could use excel to generate all the values, and then copy and paste them into the data files. It is a whole lot easier than toggling bits one at a time in RSLogix.

Plus, it gives you a design document that you can format neatly and print for reference.

Your question about using a separate subroutine to allow duplicate OTE (output coil) instructions: yes, you could do that and it can fix the problem, but can create other issues, and is not usually considered a good practice.

I would suggest sticking with one OTE per output address and we can do other things to clean up the logic to make it more efficient and readable.

So, post the .rss file (zip it first), and we can go forward from here.

Paul

 

[OkiePC]

Rev 2

This one is much improved, but all of the macro data is zero and will need to be populated. If you open two instances of RSLogix, you can drag and drop data files that you already have populated onto the files in this version, and that will move all the data.

Then, you'll want to remove the dummy steps that contain zero, since this version has a separate mechanism to ensure that the outputs are off for a period of time between commands.

To do that, open the macro data file and change the radix to decimal. Then you can drag and drop the values quite easily to take out the zeroes between steps.

 

[OkiePC]

Okay, I have copied all your macro files into my latest revision and added the logic for individual keys. Give a couple more minutes to integrate the macro selection logic and I will post something for you.

REV 3 Attached

Look at this version. It uses indirection for the file and the step, and has a separate timer to control the off time between steps. It has all your macro data plus some spares for up to 32 total macros. I tested it with RSLogix Emulate, so you may need to change the communication path back to your DF1 driver if you want to download and test this.

 

[xcode]

Hi OkiePC.

Thank you for the new file. I will work with it to learn another path.


And I am using RSLinx Classic Lite

thanks.

 

[OkiePC]

Rev 3a ooops...

Added logic to prevent switching files in the middle of a macro...

EDIT: You'll need to change the constant for the Hi Limit in the LIM block (on rung 12 and again on rung 16) from 39 to 41 in order to be able to run macros 31 and 32...

 

[xcode]

Wow.. so much food for thought. Thank you...

I just got the other REV 002 working with 18 macro's completed..

I see rev 3 has a completely different path structure. I will work with this one also to learn another approach.

Thank you .

 

[xcode]

Excellent work on rev 003a.. that is the way to have it right there. I can control the on and off time, the entery of the macro is easy to me. The HMI works flawless with everything.

Thank you so much.... everyone...

I will be making my interface board tonight for the PLC to the motherboard on my mill. We will soon have a real time test.

 

[Lancie1]

Great program, Paul! It looks like Rev 3A will do the job for Xcode.





:site:

 

[OkiePC]

:nodi:

Thanks for the kind compliments...
Paul

 

[xcode]

Okie, I have a problem. I have now hard wire tested. It works great from the single button push standpoint. My LONG Marcos have a problem in the screen change.
I dont want to slow down the smaller macros ( only 8 elements of data ), I have a longer one however that required 12 elements. then the screen was not changing fast enough with the keystrokes so I put in one stroke to occupy the time delay based on that one long macro, and not having to slow down the rest of the macros. However, extending the address table to 20, now creates that the macro running stops at element 11 ( 0-10 ) ..

What I see as a solution is to get the running macro to run past the bit 11 problem, I can setup the 2nd macro path if I need to have a what would be considered short macro path so the speed is there, long macro path so the time can be set for that path.

OR is there a way to control individual bit flow as it is passing in the processor?

Attached is 003B .. work with this one. I had a error in one keystroke so far I have found.
You will see what I did in B26 - Macro_Warm that has the issue with the length being too long in bits, and I added the 1's for dead strokes. If it is just 0's there, the Marco stops running.

 

[OkiePC]

That's easy to fix. There is a LES in rung 12 and a LIM in rung 16 that need to be changed.

I suggest you expand all the macro data files to 20 elements to guard against indirect addressing errors...

EDIT: Having macros that are shorter will automatically make them finish early, since the first time a zero is encountered (for the whole group of macro bits), the macro ends.

I am not clear what you mean by dead strokes and timing issues. Do we need to add another layer of control so each step for each macro can have it's own on delay (or off delay)? Or is it enough if we add some delay time to only those macros that get past, say 5 steps?

That isn't really hard to do if the results would be better.

 

[xcode]

What the only issue is for far is that like this....

MD enter... the lovely 286SX computer needs to execute this and get ready for the next command. which is M3S1111

I can slow the timing down I know and get, but the whole macro runs slow, and it effects the short macros.

I was thinking a path for short macros to have the speed in those because no screen changes are needed. Another path for the long macros..

 

[OkiePC]

Okay, so how can we tell when we need an added pause?

If there are more than "x" steps?

After every Enter command?

Or is there more to the pattern than that?

 

[xcode]

I think the enter command would be good indicator to try and work with.

 

[OkiePC]

Okay, I got an idea. put a -1 in the step value when you want to add a delay. A negative one in binary is all ones.

When we see this, we'll execute another timer and I'll call it screen change delay. Just put that extra step in only the macros that require it.

Rev 4 coming soon...

EDIT: I see we cross posted, do you like my idea?