PLC Programming Structure Question

[OkiePC]

I think you guys are making this all way too complex.

I think that you can use an on delay and an off delay for each input and tune them until it's near perfect.

I think that you will end up with about a 6 or 7 millisecond scan time in a ML1000.

The inputs have adjustable filters to make them more or less sensitive to very short pulses. Be sure to have a look at those settings.

I am not sure how the strum bar works (never played the game, but watched my kids once about a year ago) but it sounds like it needs to be on if any of the outputs are on? That's a very simple rung.

I can't see any need for SQO or bit shifting, just an off delay that seals in the output long enough to cover the gaps between successive notes.

Make the on delay and off delays independent for each sensor so that they can be fine tuned to deal with any variation in the alignment.

One thing that may throw a monkey wrench into the works would be the change in speed of the notes flying by.

If you are slick, though, you can detect that rate by measuring the dwell time of the sensors and adjusting a "master timer scale factor" to compensate...

That would be pretty simple, too, if you had floating point, but can still be done with integer math...

1/8 second = 0.125 seconds...typical ML100 scan time < 0.010 seconds...no problem...

If you used a ML1500, you might have ten times the speed (and double the budget) but it might make the difference between a great score and a perfect one...

I would start simple like I described, then measure the performance, tweak the timers, and only then look at things like immediate inputs and interrupts if absolutely necessary.

 

[kevilay]

I think you guys are making this all way too complex.

I think that you can use an on delay and an off delay for each input and tune them until it's near perfect.

I think that you will end up with about a 6 or 7 millisecond scan time in a ML1000.

The inputs have adjustable filters to make them more or less sensitive to very short pulses. Be sure to have a look at those settings.

I am not sure how the strum bar works (never played the game, but watched my kids once about a year ago) but it sounds like it needs to be on if any of the outputs are on? That's a very simple rung.

I can't see any need for SQO or bit shifting, just an off delay that seals in the output long enough to cover the gaps between successive notes.

Make the on delay and off delays independent for each sensor so that they can be fine tuned to deal with any variation in the alignment.

One thing that may throw a monkey wrench into the works would be the change in speed of the notes flying by.

If you are slick, though, you can detect that rate by measuring the dwell time of the sensors and adjusting a "master timer scale factor" to compensate...

That would be pretty simple, too, if you had floating point, but can still be done with integer math...

1/8 second = 0.125 seconds...typical ML100 scan time < 0.010 seconds...no problem...

If you used a ML1500, you might have ten times the speed (and double the budget) but it might make the difference between a great score and a perfect one...

I would start simple like I described, then measure the performance, tweak the timers, and only then look at things like immediate inputs and interrupts if absolutely necessary.

So When you detect and input use a timer on? then when do you timer off?

My reasoning behind bit shifts was the following:

I can get an input, delay it 500ms shifting it over several bits, then hold the note for say 3 bits for say 30ms then strum only on the middle bit.

ex.

Shift
1 0 0 0 0 0 0 1 1 1
So this first 1 is an input, when any of the 3 right most bits are 1 press that colour, for strum just press it when then 2 most right bit is a 1, this way it holds the note slightly before and after the strum, this is a more human reaction. The game will understand it better.

Kevin

 

[OkiePC]

Sounds like the strum action may make the bit shift useful, and you understand it better than I do, so by all means do what you think will work.



Below is what I had in mind for simple on delay and dwell times for each note. Set the dwell time long enough to cover the gaps between notes, and the output will stay on the whole time...

 

[kevilay]

You know how there is those S bits that are like 20ms or 40 ms depending on which one you use. Is that any different from using a timer? If I was using a bitshift shifting on a timer.

Kevin

 

[OkiePC]

I think the s bits you're talking about are the free running clock.

Clock rates for S:4/0 to S:4/7 are: 20, 40, 80, 160, 320, 640, 1280, and 2560 ms.

So the fastest one would be the same as a timer with a timebase of .01 and a preset of 2.

I went back to your first post and watched that youtube video. Are you going to be "playing" the game at that same speed? It looks a little bit too fast to me...

 

[kevilay]

I have the inputs all wired up already, they read the notes fine. Does using a s4 bit thats the same value as a timer have the same effect? or is it better to use a bit?

Kevin

 

[OkiePC]

The same effect...your PLC scan time is going to be the determining factor on the resolution of the switching speed of the outputs...

Are you using a Micrologix with DC inputs and outputs? The DC version will have a faster switching speed than the relay or AC versions...

If your sensors are able to pick up all the pulses, then you might be okay.

I would try this to measure the duration of the input pulses as seen by the PLC. Then run the thing and have a look at the values you get in the N7 file. That will give you a good idea how repeatable your inputs are and may give a clue where to start on the timing of things.

 

[Lancie1]

Kevin,

1. I think you confused the issue when you switched threads. Here are your earlier ones on this same subject, for those just tuning in and trying to igure out what you need.

http://www.plctalk.net/qanda/showthread.php?t=51024

http://www.plctalk.net/qanda/showthread.php?t=51035

At first I (and many others apparently) thought you wanted a PLC to simulate music being played, with data files to store the notes. That takes a lot of file space, and thus the early comments about using a larger PLC, timing issues, Bit-shifting, and so on.

2. Now I think what you really are wanting is simply to use the PLC as a "musician simulator", an interface device that reads in notes ands strumming from the Rockband game, to PLC Inputs, and then passes those notes to the PLC outputs to generate signals to a "guitar".

Number 2 is much simpler to do and will run on a very small PLC, and like Paul said earlier, it should only require two timers for each input. Forget about the Status (S2) clock bits, forget about shift registers, FIFO, FFL, IM, IMO, and all the other stuff. These were well-meaning suggestions, but they were based on the assumtion that you wanted to play music using the PLC as a generation device. I think now that all you are doing is using the PLC as an interface (a "simulated human player" to add timing and duration to each note, to pass notes generated by this Rockband game to PLC outputs. IF that is correct, there are many here who can whip this little program off in a few minutes. Let us know!

EDIT: Actually I think you only need ONE timer (for each note color). Having watched many guitar players (and tried one a few times), as long as you keep your fingers on a chord, and keep strumming, you get the same sound repeated. To simulate that in your PLC, you only need to delay for a short time, then have the output keep repeating until the input changes. That only takes one timer.

On the other hand, the Strum input probably does need two timers, one for the short delay before activation, and the second to set the duration.

I think what you will find is that the delay time and the time between strums will keep changing throughout the typical guitar solo. Concert music this is not, the timing changes with the tempo of the typical rock song. So your bigger problem may be how to speed up and slow down the strumming based on the tempo. Perhaps you don't have to worry about the tempo, as you are just responding to the tempo of the game, so as it speeds up, your strumming input should operate faster. The only thing left will be the strumming duration. Do you see any easy way to detect how long each strum should be? If so, the time duration of each software timer in a PLC can be adjusted on-the-fly while the program is running.

 

[Christoff84]

Not to take away from the thread, but having played guitar hero myself, how are you going to handle the notes that need to be held on for 2 to 15 seconds? Just treat them like regular notes or play with the strum timer?

I don't think timing will be too much of an issue, the game is meant for people to play, so 10-50ms reactions shouldn't hurt his program.

 

[Lancie1]

If the notes are being seen by the inputs, the note outputs will stay on as directed. The sound output will need to be a Boolean AND combination of the color inputs and the strum input as modified by the timing. The key will be the strumming timers. They probably need to be somewhat flexible.

But hey, I know a little about PLC programming, but when it comes to music, I am tone deaf.

 

[Lancie1]

Here is a quick shot at one method, just to get the ball rolling. The ZIP file is the *.RSS file type, a PLC program set up for an Allen-Bradley MicroLogix 1000 PLC, and saved as RSLogix Version 4.5.00.

I rearranged the Input and Output numbers slightly from what Kevin initially suggested. For me the Strum is sort of different and special, so I assigned it to "0" for all the timers and stuff, and the 5 notes are now 1 through 5 for green, red, yellow, blue, and orange. These numbers make no difference to how it works (if it works!)

 

[kevilay]

Not to take away from the thread, but having played guitar hero myself, how are you going to handle the notes that need to be held on for 2 to 15 seconds? Just treat them like regular notes or play with the strum timer?

I don't think timing will be too much of an issue, the game is meant for people to play, so 10-50ms reactions shouldn't hurt his program.

It doesnt detect a hold, but it just strums the note and holds it untill another note comes up. Know what i mean? Like on a green note it will hold it until it needs to let go.

Kevin

 

[kevilay]

Here is a quick shot at one method, just to get the ball rolling. The ZIP file is the *.RSS file type, a PLC program set up for an Allen-Bradley MicroLogix 1000 PLC, and saved as RSLogix Version 4.5.00.

I rearranged the Input and Output numbers slightly from what Kevin initially suggested. For me the Strum is sort of different and special, so I assigned it to "0" for all the timers and stuff, and the 5 notes are now 1 through 5 for green, red, yellow, blue, and orange. These numbers make no difference to how it works (if it works!)

I think your misunderstanding the whole situation. If you watch the youtube video on my first post it shows how rockband works. Every note that passes clicks the input on. I just need to play the outputs accordingly with a little cushion. It has nothing to do with real instruments or even music really.

Kevin

 

[Christoff84]

Having thought about this a little more, it seems to me that the only real data you need to hold is the data for the time between the notes being seen, and the strum. As previously mentioned, this is a good application for the STI.

Setup a ladder that would scan on the STI delay (10ms) taking readings from the sensors once every other scan (so 20ms intervals, bit shift runs on a positive edge I believe). I would probably setup an immediate input in this file, just to make sure you catch an I/O update. Using a bit shift (BSL), store the sensor state data in 5 different locations (B10 thru B14) one for each note.

The trick would be finding how far into the bit shift you would need to look to change notes and strum, that could be done through trial and error. If you figure every position in the bit shift is ~20ms apart, just make an educated guess and work from there.

For example, if you're bit shift register is B10/0 to B10/50 (approx 1 second of data) then you could look at B10/5 which would be ~100ms delay time, B10/10 would be ~200ms and so on.

From there you'd just have to structure your logic using latches/unlatches to trigger the buttons/strum bar.

Just my 0.02

 

[Lancie1]

It doesnt detect a hold, but it just strums the note and holds it until another note comes up.

You can't really "hold" a strum motion. It is either DONE, or NOT. I think you mean that the finger chording position is held until a different one comes up, all the while doing the strum for each set. My program will do that.

If you watch the youtube video on my first post it shows how rockband works. Every note that passes clicks the input on. I just need to play the outputs accordingly with a little cushion. It has nothing to do with real instruments or even music really.

Exactly. That is the way I wrote the program. It only inserts a delay between seeing the note and playing the output. I screwed up and added the tempo timer (just for a little extra credit for you) at the front of the program, so now all of you saw that and assumed that I was clueless! Please read on to the end. A program must be viewed in its totality. You cannot pull off a piece and expect it to do the whole job.

It appeared to me that the strumming and chording does get faster toward the end of the YouTube video. It could be just my perception, but I have had to set timimg for a lot of devices over the years. If I am wrong, then the timer Presets will stay the same throughout the song, so nothing is lost.

Notice that I DID NOT put any method in the program to auto-adjust the time delay for seeing and responding to the notes. If the rolling of the notes DOES speed up, then that time will also need to adjust during the music. (I think they are actually chords). I leave that to you because it is your project after all.

Having thought about this a little more, it seems to me that the only real data you need to hold is the data for the time between the notes being seen, and the strum.

Right on, and that is what I did. Don't throw it out before you figure out what it does. Yes, this could be done with a bit shift register, but you still need something (adjustable not fixed) to control the shifting, probably a timer and bit-shift register for each of the 5 finger positions. So my program just has the timers for each of the 5, without the shift registers (not needed in my opinion).

The time between the sensing and the playing is the key to making Kevin's program work. Why make it overly complicated? The time delay that I saw between the lights popping up and the strum is not that short, probably 0.50 seconds or more. If is was shorter, a human could not see and respond. I don't think there is any reason to use anything exotic for the timing function.

What I am looking forward to seeing is Kevin's mechanical picking fingers that respond to these PLC outputs!