PWM Sweeping sound output effect for alarm

[Lancie1]

If you add 6 rungs at the top of your "Main Timer Routine", and make them like the attached file, then I think you can successfully reset the horn buttons when a new HMI button is pressed. To do it, you have to create a new set of proxy relays (LAST_ON_SOUND_x) that are set ON by a one-shot immediately as each new button is pressed. Then use these proxy relays to reset all horn buttons EXCEPT the last one pressed.

If this does not reset your OLD HMI TOGGLE (or Alternating) buttons each time a NEW HMI button is pressed, then it is because the HMI is writing a "1" to the buttons on each scan of the PLC. If that is the case, then you cannot reset the HMI buttons from the PLC (without using a special HMI Button Reset bit that some HMIs have for this purpose). If you had a true Momentary-Contact button, then this would not be a problem.

 

[Lancie1]

I think it can be simplified down to only 3 rungs to reset all buttons except the last one (provided the HMI does not hold the buttons ON, but instead issues only one Set command when each button is pressed).

 

[mitureg]

This was my latest version for the Horn Morse Code messages from the other thread.

Is there a reason why the "P" contact must be a separate bit from the actual memory bit that is triggered by the Button on the HMI?

RevP worked fine.

Thank you Lancie.

 

[Albert LaFrance]

Any links for some advanced PWM sound generation using ladder programming would be greatly appreciated for reference.

Cheers,
Alex

I just found the thread I was referring to in my earlier post:
http://www.plctalk.net/qanda/showthread.php?t=76280

 

[Lancie1]

Is there a reason why the "P" contact must be a separate bit from the actual memory bit that is triggered by the Button on the HMI?

Yes, the Rising Edge bit is supposed to store whether or not the preceding bit has gone from 0 to 1. If it has, then the |P| produces a TRUE for only 1 PLC scan, going to 0 after that 1 scan. If you use the |P| address for something else, and the value of that "something else" (such as a horn button) changes, then the value of |P| is lost and then there is no record of whether the preceding bit has previously gone from 0 to 1. In your logic, you have no preceding bit, so the rung logic to the left of your |P| bit (the power rail) is Always True, so the |P| should go ON 1 scan, then OFF and stay OFF until the PLC is switched out of RUN mode.

However, the Twido Software Reference Manual, pages 190-191, says that the edge detection functions actually only work for true Inputs with address %Ixxx. To get an edge detector for %M bits, you have to use an elaborate procedure to detect the rising edge. See attached picture. (Whether this screwy quirk is really true or not, I cannot say).

If your Rev P is working, then because |P| supposedly does not work with %M bits, probably the program will still work if you remove the |P| functions and simply use the current horn button %M bit to reset all the other horn button %M bits.

 

[mitureg]

If your Rev P is working, then because |P| supposedly does not work with %M bits, probably the program will still work if you remove the |P| functions and simply use the current horn button %M bit to reset all the other horn button %M bits.

I just tested without the |P| rising and it won't work. It gets stuck on one Horn message selection on the HMI until pressed again. On the other hand the |P| works very well when used for briefly resetting all other selection except the new one.

Thank you for this. Have you got anything on this one Lancie : http://www.plctalk.net/qanda/showthread.php?t=86042?

Cheers.

 

[Lancie1]

I suppose this shows that you can't believe everything you read in a Schneider manual. Looking again, I see that their method of creating a manual one-shot has a severe error that prevents it from working. On the picture from the TwidoSuite Software Referecne manual in Post #20, the %M10 on the 2nd rung should be a NO contact instead of a NC. As it is, it will not work to create a one-shot pulse for %M11. Somebody should tell them about this error in the software reference manual.

Also from what you found, the |P| instruction actually does work with internal bits! I am getting a very low-down opinion about the TwidoSuite software manuals.

 

[mitureg]

Thank you Lancie. I am not surprised to see that the documentation is not consistent with the actual functions of TwidoSuite. I've heard lots of things about Sneider, including from french people (this is a french Corp.).

Their wikipedia page mentions quite a few acquisition in the last 10 years. I've heard that they just buy competitors out and bundle wrap their technology for already existing Sneider Technology product.

I guess this is not uncommon but Sneider doesn't seem to be very efficient at it in terms of integration and usability. As for now, I haven't got the chance to test the stability of their PLC... customer service is not a option either...

We will have an installation on board a ship soon, I think we will encounter a number of problems. I might update on that later...

 

[mitureg]

Hi there, just reviving an old thread here:

I have this PWM project to do, which is a sound alarm close to the representation in attachment.

So far what I did that works is the following:

In TwidoSuite -

3 timers:
- Timer 1 controls the ascending time
- Timer 2 controls the descending time
- Tmer 3 controls the total time (1 + 2 value) and the value %TM3.V is used to modulate the PWM.

To get a sound alarm that does a "Sweep up" type of sound, The value of the PWM.P (pitch) must be descending.

- In order to acheive this I have a constant value that is attributed to a %MW, let's say %MW := 50, then another %MW is attibuted the value of the timer 1 %TM1.V, so lets say %MW2 := TM1.V.

- after that a substraction is made and the result is put in another %MW, so %MW3 = %MW1 - %MW2.

- Then thew PWM.P := %MW3

To get a sound alarm that does a "Sweep Down" type of sound, The value of the PWM.P must be Ascending (like a normal timer). As it is, that part is pretty simple.

- So we have %PWM.P := %MW3 (ascending sound sweep), %PWM.P := %TM2.V

The next step is just to alternate both %PWM.P rung for the ascending and descending run using cascading timers.

The problem I had was that sound would go "out of phase", and then the run wouldn't be smooth in terms of the pitch (irregular). So what I did is that I added a counter that resets both timers (1 and 2) at the same time when the timer 3 (which is the master timer) ends a complete count.

This is very complicated it seems, and I was wondering if there would be any ideas for a simpler way to generate value within an interval, lets say 0-20, then 20-0, withing a %MW to feed the %PWM.P value.

Any suggestions?

Much appreciated.
Alex

 

[Lancie1]

This is very complicated it seems, and I was wondering if there would be any ideas for a simpler way to generate value within an interval, lets say 0-20, then 20-0,

Use a timer to trigger an UP/DOWN counter that first counts up from 0 to 20, then counts down 20 to 0.

 

[mitureg]

Thank you Lancie. That is a good idea!

So the way the Counter works in TwidoSuite, the first option that comes in my mind to do the "CountUP or DOWN" is to use a %S4 or 5.

That brings me to my second question, would their be any way to have more freedom (in terms of intervals or "speed") than with the system bits that are currently 1min, 1sec, 100ms and 10 ms?


Much appreciated,
Alex

 

[Lancie1]

...would there be any way to have more freedom (in terms of intervals or "speed") than with the system bits that are currently 1min, 1sec, 100ms and 10 ms?

I don't know much about the Schneider TwidoSuite software, but maybe someone else will have an idea.

 

[Peter Nachtwey]

Why hasn't someone asked the obvious? What if is the desired range of frequencies? Can a PLC generate the highest frequency?

 

[mitureg]

Hi Peter, the alarm sound must be between 0.5 and 1.5 kHz. The PLC can generate these frequency.