I have the following events:
event rstn_release_e is rise (smp.port_rstn$) #sim;
event d_dis_feedback_to_spot_e is rise (smp.port_d_dis_feedback$) #sim;
event osc_clk_e is rise (smp.port_osc_clk$) #sim;
I have to verify that when rstn_release_e event occurs the event d_dis_feedback_to_spot_e occurs after 0-2 cycles of oscillator clock (osc_clk_e).
I use the following:
expect #rstn_release_e => {[..2]*#osc_clk_e ; #d_dis_feedback_to_spot_e};
The simulation fails because for some reason the above expect "works" according simulation clock instead of oscillator clock
seems that you did not define the sampling event for the expect
expect #rstn_release_e => {[..2] ; #d_dis_feedback_to_spot_e} #osc_clk_e;
Related
I'm doing a parametric sweep of some Abaqus simulations, and so I'm using the waitForCompletion() function to prevent the script from moving on prematurely. However, occassionally the combination of parameters causes the simulation to hang on one or two of the parameters in the sweep for something like half an hour to an hour, whereas most parameter combos only take ~10 minutes. I don't need all the data points, so I'd rather sacrifice one or two results to power through more simulations in that time. Thus I tried to use waitForCompletion(timeout) as documented here. But it doesn't work - it ends up functioning just like an indefinite waitForCompletion, regardless of how low I set the wait time. I am using Abaqus 2017, and I was wondering if anyone else had gotten this function to work and if so how?
While I could use a workaround like adding a custom timeout function and using the kill() function on the job, I would prefer to use the built-in functionality of the Abaqus API, so any help is much appreciated!
It seems like starting from a certain version the timeOut optional argument was removed from this method: compare the "Scripting Reference Manual" entry in the documentation of v6.7 and v6.14.
You have a few options:
From Abaqus API: Checking if the my_abaqus_script.023 file still exists during simulation:
import os, time
timeOut = 600
total_time = 60
time.sleep(60)
# whait untill the the job is completed
while os.path.isfile('my_job_name.023') == True:
if total_time > timeOut:
my_job.kill()
total_time += 60
time.sleep(60)
From outside: Launching the job using the subprocess
Note: don't use interactive keyword in your command because it blocks the execution of the script while the simulation process is active.
import subprocess, os, time
my_cmd = 'abaqus job=my_abaqus_script analysis cpus=1'
proc = subprocess.Popen(
my_cmd,
cwd=my_working_dir,
stdout='my_study.log',
stderr='my_study.err',
shell=True
)
and checking the return code of the child process suing poll() (see also returncode):
timeOut = 600
total_time = 60
time.sleep(60)
# whait untill the the job is completed
while proc.poll() is None:
if total_time > timeOut:
proc.terminate()
total_time += 60
time.sleep(60)
or waiting until the timeOut is reached using wait()
timeOut = 600
try:
proc.wait(timeOut)
except subprocess.TimeoutExpired:
print('TimeOut reached!')
Note: I know that terminate() and wait() methods should work in theory but I haven't tried this solution myself. So maybe there will be some additional complications (like looking for all children processes created by Abaqus using psutil.Process(proc.pid) )
I have this exploit for Murder Mystery 2.
It is a tpcoins and esp exploit. When I enable the tpcoins it will turn off after a few seconds. Is there any way of making it so it stays on?
Here's the code:
function enableTpCoin()
if nameMap ~= "" and wp[nameMap] ~= nil then
if lplr.PlayerGui.MainGUI.Game.CashBag:FindFirstChild("Elite") then
tpCoin(10)
elseif lplr.PlayerGui.MainGUI.Game.CashBag:FindFirstChild("Coins") then
tpCoin(15)
end
end
Trigger to start the script is q.
Short answer, you can't. Since this is script related I'll answer your question.
So each round, the player can only earn 10 coins, and 15 if they have purchased the "Elite" gamepass.
This meaning that the game physically doesn't allow you to add anymore per round. You'll have to execute the code at the launch of every round.
The game has FE, so it's most likely that the original developer of the game has specified the remote events to only accept 10 or 15 coins depending on the boolean value whether the user is "Elite" or not.
Even if Universal Link says the truth, here's the solution.
Create a new function. In that function, do a while loop with a interval (use wait(.1)), and in that while loop, call enableTpCoin().
Now, call spawn() and pass the function you created as an argument.
The code should look like this:
function _loop()
while wait(.1) do
enableTpCoin()
end
end
spawn(_loop)
I'm taking a PCollection of sessions and trying to get average session duration per channel/connection. I'm doing something where my early triggers are firing for each window produced - if 60min windows sliding every 1 minute, an early trigger will fire 60 times. Looking at the timestamps on the outputs, there's a window every minute for 60minutes into the future. I'd like the trigger to fire once for the most recent window so that every 10 seconds I have an average of session durations for the last 60 minutes.
I've used sliding windows before and had the results I expected. By mixing sliding and sessions windows, I'm somehow causing this.
Let me paint you a picture of my pipeline:
First, I'm creating sessions based on active users:
.apply("Add Window Sessions",
Window.<KV<String, String>> into(Sessions.withGapDuration(Duration.standardMinutes(60)))
.withOnTimeBehavior(Window.OnTimeBehavior.FIRE_ALWAYS)
.triggering(
AfterWatermark.pastEndOfWindow()
.withEarlyFirings(AfterProcessingTime
.pastFirstElementInPane()
.plusDelayOf(Duration.standardSeconds(10))))
.withAllowedLateness(Duration.ZERO)
.discardingFiredPanes()
)
.apply("Group Sessions", Latest.perKey())
Steps after this create a session object, compute session duration, etc. This ends with a PCollection(Session).
I create a KV of connection,duration from the Pcollection(Session).
Then I apply the sliding window and then the mean.
.apply("Apply Rolling Minute Window",
Window. < KV < String, Integer >> into(
SlidingWindows
.of(Duration.standardMinutes(60))
.every(Duration.standardMinutes(1)))
.triggering(
Repeatedly.forever(
AfterWatermark.pastEndOfWindow()
.withEarlyFirings(AfterProcessingTime
.pastFirstElementInPane()
.plusDelayOf(Duration.standardSeconds(10)))
)
)
.withAllowedLateness(Duration.standardMinutes(1))
.discardingFiredPanes()
)
.apply("Get Average", Mean.perKey())
It's at this point where I'm seeing issues. What I'd like to see is a single output per key with the average duration. What I'm actually seeing is 60 outputs for the same key for each minute into the next 60 minutes.
With this log in a DoFn with C being the ProcessContext:
LOG.info(c.pane().getTiming() + " " + c.timestamp());
I get this output 60 times with timestamps 60 minutes into the future:
EARLY 2017-12-17T20:41:59.999Z
EARLY 2017-12-17T20:43:59.999Z
EARLY 2017-12-17T20:56:59.999Z
(cont)
The log was printed at Dec 17, 2017 19:35:19.
The number of outputs is always window size/slide duration. So if I did 60 minute windows every 5 minutes, I would get 12 output.
I think I've made sense of this.
Sliding windows create a new window with the .every() function. Setting early firings applies to each window so getting multiple firings makes sense.
In order to fit my use case and only output the "current window", I'm checking c.pane().isFirst() == true before outputting results and adjusting the .every() to control the frequency.
I'm trying to use an ESP8266 SoC to read a water flow sensor that is said to produce a square wave as output. I thought it would be a simple matter of using a GPIO port in interrupt mode, to count rising edge transitions -- and in fact that initially seemed to work. Then I upgraded the firmware from 0.96 to 1.5 and it has since ceased to work, I see no transitions when the wheel spins anymore.
However, if I run a wire to the pin [for the GPIO I'm using] and touch it to VCC momentarily, the interrupt routine is called as expected, so I know the sensor is wired to the right pin, and the interrupt routine is registered correctly. My code:
function intCb(level)
SpinCount = SpinCount + 1
local levelString = "up"
if level == gpio.HIGH then
levelString = "down"
end
gpio.trig(pin, levelString, intCb)
end
gpio.write(pin, 0)
gpio.trig(pin, "up", intCb)
gpio.mode(pin, gpio.INT, gpio.FLOAT)
So what am I missing? Do I need more support circuitry to read a square wave as input? If so then how did it work initially?
For anything that involves hardware it's really hard to give a definite answer here on SO. In most cases one bases it on hints (and hunches sometimes). A few ideas:
gpio.FLOAT should probably be gpio.PULLUP instead (unless you have an external pull-up resistor).
Your setup doesn't seem to be fundamentally different from e.g. using a push button or a switch to trigger some event. Hence, you probably want to use some kind of debounce or throttle function.
Since you seem to be interested in both rising and falling edges (as you switch between up and down) you might just as well listen for both, no?
So, assuming I drew the right conclusions something like the following generic skeleton may prove to be useful:
-- inspired by https://github.com/hackhitchin/esp8266-co-uk/blob/master/tutorials/introduction-to-gpio-api.md
-- and http://www.esp8266.com/viewtopic.php?f=24&t=4833&start=5#p29127
local pin = 4 --> GPIO2
function debounce (func)
local last = 0
local delay = 5000
return function (...)
local now = tmr.now()
local delta = now - last
-- if delta < 0 then delta = delta + 2147483647 end; proposed because of delta rolling over
if delta < delay then return end;
last = now
return func(...)
end
end
function onChange ()
print('The pin value has changed to '..gpio.read(pin))
end
gpio.mode(pin, gpio.INT, gpio.PULLUP) -- see https://github.com/hackhitchin/esp8266-co-uk/pull/1
gpio.trig(pin, 'both', debounce(onChange))
I solved this using a 555 timer chip as a schmitt trigger:
If I have a window like this:
.apply(Window
.<String>into(Sessions
.withGapDuration(Duration.standardSeconds(10)))
.triggering(AfterWatermark
.pastEndOfWindow()
.withEarlyFirings(AfterPane.elementCountAtLeast(1))));
And it receives data:
a -> x (timestamp 0) (received at 20)
a -> y (timestamp 1) (received at 21)
(watermark passes 11) (at 22)
I suppose that the window would trigger at times:
20 sec, because of an early firing
21 sec, because of an early firing
22 sec, because of watermark passing the GapDuration
In a ParDo function that I apply over the windowed data, is there a way to distinguish early firing from watermark passing the GapDuration?
According to this stackoverflow question there is no way to get the watermark. If I was able to do that, I could check max(timestamp) < watermark. But since I cannot get the watermark, is there any other way to figure out that a window was triggered by watermark passing it.
You can access the PaneInfo of the elements in a DoFn after the GroupByKey by calling ProcesContext#pane() and use that to determine the Timing. This will allow you to identify if this as an "on time" firing (due to the watermark passing the end of the window) or a speculative/late firing.