Mean Well also produces NFM-10-12, an open frame version of the same power supply. now apparently EOL, for medical equipment use purposes.
The datasheet and approval test report are also at their web site.
After you grab and read all documents from Mean Well's web site, take a look at a same-speccd power supply from Infineon (demo board), with full schematics.
The output overvoltage detection circuit seems to be the same (conceptually), based on the test reports of Mean Well products. Based on a zener diode that activates an opto-coupler, whose in turn would switch-off the PWM control circuit.
An interesting point that is made clear at Infineon speccs is the fact that many of the non-destructive abnormal input/output conditions are treated (remedy??) with an auto-restart function.
In other words, an over-something abnormal condition would trigger an auto-restart function, in the hope the problem would be non-permanent, and will not last after the auto-restart timeout (20 mS in case of Infineon speccs).
P12 clears shows a 16 msec width step function (+5VDC, 0VDC, +5VDC) every 2 seconds as shown in the attached files.....this is clearly coming out of P12. Bob, I did do as you suggested, which is to place P12 into a high mode at the very beginning of the code, line 1, and then use the "END" command directly afterwards. Again, it shows this same behavior.
Do you know that the behavior you described with 16ms dropouts at two second intervals is exactly what happens when the Stamp runs off the end of a program, either explicitly or by running out of code to execute? Or with the SLEEP command.
Hi Bob,
i ran the test today in which you suggested I provide a direct +5VDC input into R42 rather than having it driven by P12. As well P12 was wired through a current limiting resistor to a LED and then to GND. I observed similar behaviour on P12, cyclic behaviour of the voltage - for the most part P12 remained at +5VDC (HIGH) as expected but dropped to 0V about every 2 seconds with a pulse width of about 15 ms, as was observed before. The relay is not clicking on/off as before, but did activate once during power up once and seems to be in a stable ON state - the output LED is not flickering and this was verified by the oscilloscope at high accuracy - stable output.
Interestingly, I powered off the relay - out of curiosity, i.e., removed the +12VDC that powers the coil and the cyclic behaviour still is present?! Next, I removed pretty much everything except the current limiting resistor and LED...and the strange cyclic behaviour is still there?! I even moved the test setup to another room thinking there may be some bizarre interference in the room. I also added a capacitor in parallel with the current limiting resistor signal to ground, and this simply changed the waveform shape to minimize the sharpness of the step function.
To me this says the relay is not involved?! Where is this 2 second step function coming from inside the CPU....remember that i am using the BS2P24 on the BOE and the BS2P40 OEM on my proto, so i also am testing with different microprocessors - albeit, the same Pin, Pin 12.
Hi Tracy,
ok, as part of the simple troubleshooting I put the END cmd inplace....instead i changed it to a do loop with a PAUSE 1 and...the flickering vanished.
Now to backtrack and see if there is some related issue with my board....
If I where you I would workout this glitch on my BOE board. This way you can eliminate other factors that may exist on your more complex production board.
Hi Tracy,
ok, as part of the simple troubleshooting I put the END cmd inplace....instead i changed it to a do loop with a PAUSE 1 and...the flickering vanished.
Now to backtrack and see if there is some related issue with my board....
Thanks very much,
Chris.
If that is the issue, it lies with the PBASIC code, not with the board per se. It is the way the BASIC Stamp works.
When a Stamp program ends, the watchdog timer keeps running and resets the PIC or SX processor at ~2 second intervals. That causes all the pins to become inputs until state of the direction and output registers are reasserted. That takes ~16ms. There are ways to avoid the effects of the glitch by using a capacitor or something to supply current to carry through through the glitch, but the best way is usually to add that do-nothing DO:LOOP.
This is also an issue when you use the SLEEP command. For example, SLEEP 600 will cause the Stamp to sit there snoozing for 10 minutes, nevertheless, there will be that short 16ms glitch to input every 2 seconds on all pins configured as outputs.
Hello all,
i have identified root cause. The issue was with the END command. It does exactly what Tracy Allen says and provides this refresh of the pins. I searched all my code and put a debug statement in front of every END command and found one where it was being executed. I modified the code and the issue went away. By pure coincidence, i also used the END command in creating a simplified code to perform the troubleshooting which made all of the effort more tricky.
I can safely say, that I have learned exactly what the END command does now.
As always, I cannot say thank-you enough to all of the contributors on this forum! I am a single person, and being able to ask question and get advice from such an experienced group is truly invaluable.
Thank-you again and have a wonderful Memorial day long weekend everyone! Here in Canada, we celebrated last weekend, so I will have to work this coming Monday.
I'm glad that worked out, a good case of a problem cropping from an unexpected direction. That question about the effect of the glitch used to come up quite a bit on the forum, so it seems the collective memory is fading.
The reason it occurs is so that PBASIC can support the SLEEP and NAP commands, which go all the way back to the STAMP 1, and in the 'p series Stamps it extend to the POLLWAIT command. All of those use the PIC or SX chips' watchdog timer circuit, which is configured at the time PBASIC is compiled and burned into the PIC eeprom, and can't be turned off at run time. It's effect on END is an artifact of implementing those other very useful power-saving commands. Refer to NAP in the Stamp manual for the best explanation of how it works.
The glitch is shorter on the BS2pe, less than 100 microseconds, opposed to 16 or 18 milliseconds on the other Stamp species.
I have lots of experience with the BS2p24 and found it to be very sensitive to EMI from relays and solenoids. The only real solution I found was to enclose the BS2p24 and all associated circuitry in a solid shield enclosure. All power lines and sensor inputs are coax. Once this was done, everything worked properly with no problems.
Comments
-Phil
Mean Well IRM-10-12
https://meanwell-web.com/en-gb/ac-dc-single-output-encapsulated-power-supply-irm--10--12
Finally!! At least one time, my eyesight was better than someone's else! Horay!!!!
The datasheet and approval test report are also at their web site.
After you grab and read all documents from Mean Well's web site, take a look at a same-speccd power supply from Infineon (demo board), with full schematics.
https://infineon.com/dgdl/Infineon-AN_ICE3RBR4765JG-AN-v01_00-EN.pdf?fileId=5546d46253f6505701549aaf8de0751e
The output overvoltage detection circuit seems to be the same (conceptually), based on the test reports of Mean Well products. Based on a zener diode that activates an opto-coupler, whose in turn would switch-off the PWM control circuit.
An interesting point that is made clear at Infineon speccs is the fact that many of the non-destructive abnormal input/output conditions are treated (remedy??) with an auto-restart function.
In other words, an over-something abnormal condition would trigger an auto-restart function, in the hope the problem would be non-permanent, and will not last after the auto-restart timeout (20 mS in case of Infineon speccs).
Oranges and beetle eggs. Isn't a fair compare...
Do you know that the behavior you described with 16ms dropouts at two second intervals is exactly what happens when the Stamp runs off the end of a program, either explicitly or by running out of code to execute? Or with the SLEEP command.
i ran the test today in which you suggested I provide a direct +5VDC input into R42 rather than having it driven by P12. As well P12 was wired through a current limiting resistor to a LED and then to GND. I observed similar behaviour on P12, cyclic behaviour of the voltage - for the most part P12 remained at +5VDC (HIGH) as expected but dropped to 0V about every 2 seconds with a pulse width of about 15 ms, as was observed before. The relay is not clicking on/off as before, but did activate once during power up once and seems to be in a stable ON state - the output LED is not flickering and this was verified by the oscilloscope at high accuracy - stable output.
Interestingly, I powered off the relay - out of curiosity, i.e., removed the +12VDC that powers the coil and the cyclic behaviour still is present?! Next, I removed pretty much everything except the current limiting resistor and LED...and the strange cyclic behaviour is still there?! I even moved the test setup to another room thinking there may be some bizarre interference in the room. I also added a capacitor in parallel with the current limiting resistor signal to ground, and this simply changed the waveform shape to minimize the sharpness of the step function.
To me this says the relay is not involved?! Where is this 2 second step function coming from inside the CPU....remember that i am using the BS2P24 on the BOE and the BS2P40 OEM on my proto, so i also am testing with different microprocessors - albeit, the same Pin, Pin 12.
Regards,
chris.
ok, as part of the simple troubleshooting I put the END cmd inplace....instead i changed it to a do loop with a PAUSE 1 and...the flickering vanished.
Now to backtrack and see if there is some related issue with my board....
Thanks very much,
Chris.
If that is the issue, it lies with the PBASIC code, not with the board per se. It is the way the BASIC Stamp works.
When a Stamp program ends, the watchdog timer keeps running and resets the PIC or SX processor at ~2 second intervals. That causes all the pins to become inputs until state of the direction and output registers are reasserted. That takes ~16ms. There are ways to avoid the effects of the glitch by using a capacitor or something to supply current to carry through through the glitch, but the best way is usually to add that do-nothing DO:LOOP.
This is also an issue when you use the SLEEP command. For example, SLEEP 600 will cause the Stamp to sit there snoozing for 10 minutes, nevertheless, there will be that short 16ms glitch to input every 2 seconds on all pins configured as outputs.
i have identified root cause. The issue was with the END command. It does exactly what Tracy Allen says and provides this refresh of the pins. I searched all my code and put a debug statement in front of every END command and found one where it was being executed. I modified the code and the issue went away. By pure coincidence, i also used the END command in creating a simplified code to perform the troubleshooting which made all of the effort more tricky.
I can safely say, that I have learned exactly what the END command does now.
As always, I cannot say thank-you enough to all of the contributors on this forum! I am a single person, and being able to ask question and get advice from such an experienced group is truly invaluable.
Thank-you again and have a wonderful Memorial day long weekend everyone! Here in Canada, we celebrated last weekend, so I will have to work this coming Monday.
Sincerely,
Chris.
The reason it occurs is so that PBASIC can support the SLEEP and NAP commands, which go all the way back to the STAMP 1, and in the 'p series Stamps it extend to the POLLWAIT command. All of those use the PIC or SX chips' watchdog timer circuit, which is configured at the time PBASIC is compiled and burned into the PIC eeprom, and can't be turned off at run time. It's effect on END is an artifact of implementing those other very useful power-saving commands. Refer to NAP in the Stamp manual for the best explanation of how it works.
The glitch is shorter on the BS2pe, less than 100 microseconds, opposed to 16 or 18 milliseconds on the other Stamp species.
Hey! I resemble that remark! :-D
Glad to read that the problem was understood and resolved.
Sincerely,
Discovery