I work for a semiconductor manufacturer. We are often trying to test our designs to make sure that sequences we run on our parts properly connect two points on a schematic for example signal_a and signal_b. The two signals usually have multiple pass gates that have to be turned on to connect the two signals. To check that this happens correctly we usually go through the schematic and simulation to check that all the pass gates were turned on correctly. It seems like Verilog would already have a built in command for checking this. For example something similar to:
#triggering_signal
begin
connected=check_connection(signal_a,signal_b)
end
connected would be set to 1 if they are connected and to 0 if they are not. I would appreciate it if anybody could point me in the correct direction if something like this exists. Note I thought of putting a force signal in the code to toggle signal_a and seeing if it shows up at signal_b using a counter, but this does not work for all the cases I need due to the fact that signal_a being at any other state than 1 turns the die off.
You can try to use SV assertions using sequence to test that signal_a value is always same as signal_b.
assert (signal_a == signal_b) else $error("It's gone wrong");
Related
I'm trying to log data points for the same metric across multiple runs (wandb.init is called repeatedly in between each data point) and I'm unsure how to avoid the behavior seen in the attached screenshot...
Instead of getting a line chart with multiple points, I'm getting a single data point with associated statistics. In the attached e.g., the 1st data point was generated at step 1,470 and the 2nd at step 2,940...rather than seeing two points, I'm instead getting a single point that's the average and appears at step 2,205.
My hunch is that using the resume run feature may address my problem, but even testing out this hunch is proving to be cumbersome given the constraints of the system I'm working with...
Before I invest more time in my hypothesized solution, could someone confirm that the behavior I'm seeing is, indeed, the result of logging data to the same metric across separate runs without using the resume feature?
If this is the case, can you confirm or deny my conception of how to use resume?
Initial run:
run = wandb.init()
wandb_id = run.id
cache wandb_id for successive runs
Successive run:
retrieve wandb_id from cache
wandb.init(id=wandb_id, resume="must")
Is it also acceptable / preferable to replace 1. and 2. of the initial run with:
wandb_id = wandb.util.generate_id()
wandb.init(id=wandb_id)
It looks like you’re grouping runs so that could be why it’s appearing as averaging across step - this might not be the case but it’s worth trying. Turn off grouping by clicking the button in the centre above your runs table on the left - it’s highlighted in purple in the image below.
Both of the ways you’re suggesting resuming runs seem fine.
My hunch is that using the resume run feature may address my problem,
Indeed, providing a cached id in combination with resume="must" fixed the issue.
Corresponding snippet:
import wandb
# wandb run associated with evaluation after first N epochs of training.
wandb_id = wandb.util.generate_id()
wandb.init(id=wandb_id, project="alrichards", name="test-run-3/job-1", group="test-run-3")
wandb.log({"mean_evaluate_loss_epoch": 20}, step=1)
wandb.finish()
# wandb run associated with evaluation after second N epochs of training.
wandb.init(id=wandb_id, resume="must", project="alrichards", name="test-run-3/job-2", group="test-run-3")
wandb.log({"mean_evaluate_loss_epoch": 10}, step=5)
wandb.finish()
I am using opencv and openvino and am trying to figure out when I have a face detected, use the cv2.rectangle and have my coordinates sent but only on the first person bounded by the box so it can move the motors because when it sees multiple people it sends multiple coordinates and thus causing the servo and stepper motors to go crazy. Any help would be appreciated. Thank you
Generally, each code would run line by line. You'll need to create a proper function for each scenario so that the data could be handled and processed properly. In short, you'll need to implement error handling and data handling (probably more than these, depending on your software/hardware design). If you are trying to implement multiple threads of executions at the same time, it is better to use multithreading.
Besides, you are using 2 types of motors. Simply taking in all data is inefficient and prone to cause missing data. You'll need to be clear about what servo motor and stepper motor tasks are, the relations between coordinates, who will trigger what, if something fails or some sequence is missing then do task X, etc.
For example, the sequence of Data A should produce Result A but it is halted halfway because Data B went into the buffer and interfered with Result A and at the same time screwed Result B which was anticipated to happen. (This is what happened in your program)
It's good to review and design your whole process by creating a coding flowchart (a diagram that represents an algorithm). It will give you a clear idea of what should happen for each sequence of code. Then, design a proper handler for each situation.
Can you share more insights of your (pseudo-)code, please?
It sounds easy - you trigger a face-detection inference-request and you get a list/vector with all detected faces (the region-of-interest for each detected face) (including false-positive and false-positives, requiring some consistency-checks to filter those).
If you are interested in the first detected face only - then it could be to just process the first returned result from the list/vector.
However, you will see that sometimes the order of results might change, i.e. when 2 faces A and B were detected, in the next run it could still return faces, but B first and then A.
You could add object-tracking on top of face-detection to make sure you always process the same face.
(But even that could fail sometimes)
I have been trying to set up a custom manipulation station with Kuka IIWA hardware in drake. I got the hardware interface working. When running a joint teleoperation code (adapted from drake/examples/manipulation_station/joint_teleop.py), the robot jerks violently (all joints tries to move to 0 position) at first and then continues to operate normally. On digging deeper, I found that this is caused by the FirstOrderLowPassFilter system. While advancing the simulation a tiny bit (simulator.AdvanceTo(1e-6)) to evaluate the LCM messages to set the initial GUI sliders-filter_initial_output_value-plant joint positions etc., to match the hardware, the FirstOrderLowPassFilter outputs a momentary value of 0. This sets the IIWA_COMMAND position to zero for an instance and causes a jerk.
How can I avoid this behavior?.
As a workaround, I am subscribing separately to the raw LCM message from the hardware, before initializing the drake systems and sets the filter_initial_output_value before advancing the simulation. Is this the recommended way?.
I think what you're doing (manually reading the LCM message) is fine.
In the alternative, look how a DiscreteDerivative offers the suppress_initial_transient = true option. Perhaps we could add a similar option (via unrestricted update event) to FirstOrderLowPassFilter so that the initial output value was sampled from the input at t == 0. But the event sequencing of startup may still be difficult. We essentially need to initialize the systems in their dataflow order, including refreshing output ports as events fire, which is not natively supported.
In another alternative, perhaps we could configure the IIWA_COMMAND publisher to not publish at t == 0, instead publishing only t >= 0.005.
FirstOrderLowPassFilter has a method to set the initial value. https://drake.mit.edu/doxygen_cxx/classdrake_1_1systems_1_1_first_order_low_pass_filter.html#aaef7539cfbf1acfa0cf487c371bc5360
It is used in the example that you copied from:
https://github.com/RobotLocomotion/drake/blob/master/examples/manipulation_station/joint_teleop.py#L146
MQL4 codes are written in C language and basically, there is no method to use error detecting mechanism in C language before executing the code. Is there a special functionality in the Mql4 platform which helps to catch runtime errors before it executes?
No. you cannot throw an error, and you cannot catch it. So be very careful, check that b!=0 before dividing a by b, check that idx>=0 and idx<array.size before accessing array[idx] and check CheckPointer(object)==POINTER_DYNAMIC before calling something with object.
There isn't a mecanisn in mql of detect the errors before executing the code.
So besides the basic checkings of the range limits in the arrays, divisions by 0, passing the parameters witht the right range (price, sl, tp...) to the operations etc. the best way of finding most of the errors is running a backtest of the strategy you have built for several months using M1. The strategy tester is available on Metatrader.
During the backtesting Metatrader is going to feed your code with a lot of data simulating the actual market, so the code is going to pass through a lot of situations/routines/functions that is going to find later in the actual trading.
The back testing is the best simulation you can do, testing not only the strategy, testing the code itself.
This is not going to guarantee a 100% error free code, but in my case it finds >99% of them.
I have a channel that I want stop animations from happening if running on a slower device like Roku Express and keep them on a faster device like Roku Premiere. Except I'm not sure what's the best way to go about it.
I wanted to filter by the amount of available ram, but I couldn't find an api that gives me available ram for the system that I could run in my code.
I could filter by model name, but I would then need to keep an update list of model names, which I prefer not to do.
Any help/insight appreciated.
Re graphic capabilities, try roDeviceInfo.getGraphicsPlatform() - if it returns opengl, that high performing engine that can do arbitrary rotations vs directfb being limited.
Re CPU, you can run a mini benchmark on start of your program, something like
ti = createObject("roTimeSpan"): s=""
for i = 1 to 1000: s = s + right((i^3).toStr(),2): end for
time = ti.totalMilliSeconds()
Have you considered using Animation.optional=true?
It won't stop them from happening on Roku Express (since it is a Littlefield) but it will "skip animations on lower performing Roku devices (Paolo, Giga, Jackson, Tyler, and Sugarland)".
Animation also contains an undocumented field called "willBeSkipped" which will be true on slower devices when "optional" is set to true.
I had the similar problem with the animations. Unfortunately, You must filter by model name. I didn't find another way.
You can store the list of devices in database so it would be easier for You to maintain.
You can set the optional field on the animation node to true. This is supposed to take care of that. I have set this field to true before and it does not seem to have an effect. I'm sure they'll get around to fixing it eventually.
The efficiency of the animations also depends on how many animation nodes you have. You should only need 1 animation node to handle all of your animations for a particular component. Add an interpolator for each individual type of animation you want to occur (i.e. scaling, rotating, color-shifting, translating).