the projects has 4 states in total:
at start , the green traffic light and the red footwalker light is active
when pushbutton is pressed the yellow light of traffic lights becomes active and the red footwalker light still remains active while the timer starts for 3 seconds.
in next state, the traffic light turns to red while the footwalker light turns to green and another timer starts for 20 seconds.
in next state, after the timer expires the traffic light becomes yellow again and the footwalker light becomes red and the first timer runs again for 3 seconds. the program returns to its initial state after the completion.
[State diagram][1]
the circuit diagram implemented in profilab is shown in the image given below:[Circuit][2]
I have been trying since last week and i have successfully implemented 3 states in profilab expert4.0 but i am unable to execute the 4th state. if i implement the 4th state, the whole program stops working.
the content of the ROM for the working example is:[ROM contents][3]
If someone helps me with this problem, i shall be eternally thankful to that person and it would mean a lot to me.
[1]: https://i.stack.imgur.com/pn9gr.jpg
[2]: https://i.stack.imgur.com/vixPU.jpg
[3]: https://i.stack.imgur.com/eINHy.jpg
Related
Light up LEDs one at a time up to 21 and then shut off.
All controlled by a button push.
Simplest way possible as I am not well versed in electrical wiring.
I have objects with 3 different colors:
black, dark green, and bright blue.
When I take pictures of them, I do not yet know the real color of the object, thus my image can only be so bright that the bright blue object does not blow out to white. If I make the bright blue as bright as I can, then the dark green and the black are still very dark. Almost too much.
Is there anything that can be done beside brightening up the images afterward?
the camera is a Genie Nano.
If there is enough time, you could take multiple images with different exposure times. There is even a ready method in Halcon to merge light and dark images "create_high_dynamic_range_image.hdev".
If your application is time critical and camera manufacturer provides events for the language you're working in you can do the following:
Put the camera in asynchronous acquisition (reduces time)
Start acquisition with the lowest desired exposure time
On each image event increase the exposure time for some step N times
Since the camera is in asynchronous acquisition each exposure time comes after M frames (usually 5)
First M images should be ignored, and after that you will have N-M images with gradually increased exposure time
I am designing a system where a light sensor detects light in a room and based on that it adjusts the output of a few light bulbs. The goal is to maintain a standard level of light in the room based on the environmental conditions such as external sunlight. The code is written in Python and uses Phillips hue bulbs to function. The pseudocode is as follows:
if (read light is in between 10 - 50 lumins) {
set bulb to 100 lumins
}
if (read light is in between 51-100 lumins) {
set bulb to 50 lumins
}
etc
However what ends up happening is that after each iteration, when the light is set to the specific value, the sensor detects the bulbs' own light and on the next iteration turns down the light. The lights end up flickering from high to low every second. Does anyone have any experience with this sort of thing, of an algorithm to deal with it? Essentially, the problem is that the light sensor is detecting the bulbs' own light and then undoing its previous decision. I am using a standard TSL2561 sensor to detect the light and the bulbs are Phillips hue.
The placement of the sensor is key in these situations. You can also try an optical filter but that is not the full solution.
Your algorithm is to crude to compensate for a dynamic environment. The real solution is to use a PID algorithm to make small adjustments over time to the light output to stay close to an ideal total (ambient+LED) light level.
See this example, there is many similar out there if you search for pid controller light sensor.
A simplified pseudo code representation for a PID like control system would be:
read in_lumins
if (in_lumins is in between 10 - 50 lumins) {
increment out_lumins
}
if (in_lumins is in between 51-100 lumins) {
decrement out_lumins
}
set bulb to out_lumins
Loop and repeat. Time increments on loop and/or increment size should vary with distance from ideal.
I have an Arduino starter set, which came with both an active and a passive buzzer. Unfortunately, I can't seem to know which is which. All I know is that one is a little longer than the other one, on which I can see the green circuit board underneath.
An active buzzer generates the sound itself. You basically just turn it on or off.
A passive buzzer needs a signal source that provides the sound signal.
To find out which is which you can measure the resistance between both leads. If it is a few Ohms its the passive one, higher values indicate an active one.
Also the active one will have it's own circuitry (the pcb you can see) and will therefor be probably bigger.
But I guess your arduino package comes with a parts list that should give you all information you need?
"Programatically" speaking:
Active Buzzer: using a simple digitalWrite(buzzerPin, HIGH) will turn the beep on, once it has a internal oscillator.
Passive Buzzer: you need to use Tone() function in order to make it beep. Once it has no internal oscillator you need to use Tone() function to create the frequency it will oscillate. Check the Tone() reference page to learn how to use it, but is quite simple, you just need to enter as parameter pin and frequency like Tone(3, 440), will generate a 440Hz on passive buzzer hooked up to pin 3.
To stop a active buzzer you need to use digitalWrite(buzzerPin, LOW), while with a passive buzzer you need to use noTone(passiveBuzzerPin).
How to distinguish passive buzzer and active buzzer?
There are several ways to distinguish passive buzzer and active buzzer.
The most simple method is to watch their different appearances.If you can see a drive board,it is passive buzzer.If the buzzer is completely covered by black adhesive,it is active buzzer.
https://www.keliking.com/Differences-Between-Passive-Buzzer-and-Active-Buzzer-id570060.html
They come in all shapes and sizes, so don't assume "long" means one thing or another. The passive buzzer has only a small piezo on the module's PCB. An active buzzer will have a couple other small components on the pcb, like an amp and resistor(s).
In the Freenove Arduino kit that i bought, the passive buzzer is the one with the green on the bottom and the active is the one without, and is slightly taller with varied hights of the pins
Physical distinction between the two.
Slight disclaimer first. . . the buzzers I have are from one of those 27 piece sensor kits. For me it was an extra buy from "30 Days Lost In Space". After my pieces all got mixed together, I've decided to lay them all out & know what each one does. Yours may be different
Here's what I observed. If you have the connections down and the buzzer away from you so you're looking at the back of the board There are solder points. The upper left solder point is filled on the active buzzer. note don't count the larger mounting hole on the very edge. In the photo, I've highlighted the filled solder hole on the active buzzer.
highlighted solder point on active buzzer -- left vs passive buzzer -- right
I had this same question, which led me here. The other answers were helpful in and of themselves, but I noticed the difference after testing, and hopefully someday this may help someone else who may be new, as I am now.
I've been at arduino just shy of 2 weeks.
I have a number of Philips Hue bulbs at home, but they are only used pretty much like classic on/off-no-color light bulbs today, mainly because I do find electric switches more useful than pulling out my iPhone or correct HueTap just to turn the light on/off. - Every time the Hue bulb is switch off, it forgets its state and always comes back on at 100% brightness in white color.
After lots of googling (and not finding any solutions) I wonder whether I am missing the point and why others do not have this problem.
I am certainly not keen on doing software or even hardware work here, but if I had a reasonable idea I'd love to evaluate such path:
is there anything planned from Philips to fix this? The last firmware update did not help and Philips product support explained that this is not a bug, it is just the way it is designed.
any new "stateful" bulbs?
any work-arounds like patched / custom bulb or bridge firmware?
any recommendation on how to tackle this problem?
Assuming the Hue bulbs themselves do not have any memory installed, I guess they always switch on at 100% brightness and then register with the bridge? And this would be the earliest possible moment to restore the previous state?
Can this problem be solved using Hue SDK? (how long does it take for a turned on bulb to be controllable by the Hue Bridge? What is the quickest way for a Java program to get notified of a bulb being electrically turned on?)
any chance to get the previous state restored in a quicker way if using some ZigBee protocol/techniques directly?
Any hints are much appreciated.
Best regards,
Christian
I agree that it might be irritating that the last state of a light bulb is not being preserved. There is a thread on the developer site of Hue, which gives some insight:
Apparently, there are internal discussions on this topic. The team at Philips hesitates to implement a restore of the previous state due to "security reasons": A user could be left in the dark, if she uses the electrical switch, but the previous state was "off". This opinion has been reiterated in a tweet. There is no definite conclusion in the thread yet.
You can do a workaround and continuously record the state of each bulb, and restore, if necessary. There is a Node.JS script on GitHub that seems to be doing exactly this. If you want to run this as a stand-alone solution, buy a Raspberry Pi (or something similar).
One problem with an SDK based solution is the latency: In my setup, it takes between 3-9 seconds to recognize a light bulb as being switched on and about 20-30 seconds to recognize a light bulb being switched off.
Here is my Python code for monitoring the reachability of my light bulbs, using python-hue-client:
from hueclient.api import hue_api
from hueclient.models.light import Light
from datetime import datetime
from subprocess import call
if __name__ == '__main__':
my_ids = (1, 4, 5) # IDs of my light bulbs
def handle(resource, field, previous, current):
print "{} {}: changed reachability from {} to {}".format(datetime.now().isoformat(), resource.name, previous, current)
hue_api.authenticate_interactive(app_name='test-app')
# register my light bulbs
for id in my_ids:
light = Light.objects.get(id=id)
print "{}: reachability is {}".format(light.name, light.state.reachable)
# Monitor only the reachability of the light
light.monitor(field=lambda l: l.state.reachable, callback=handle, poll_interval=0.1)
print("Starting monitoring. Control-c to exit.")
# Start the monitoring loop
hue_api.start_monitor_loop()