I am using CAPL to control the power supply.
I need to add a delay in my script, since I am not using the test node testwaitfortimeout() function can't be used.
I tried giving the delay using while loop and timer function, but this crashes CANoe.
Is there is any other way to add a delay?
Related
I have a JMeter (5.3) While Controller in a 1-user Thread Group, it reads a CSV and makes http calls for each row. I want all of these to complete as fast as possible (i.e. the loop completes uninterrupted), then the thread-group should pause, then I want the csv-loop to repeat*.
This is proving oddly difficult. Adding a Constant Timer below the While and it's (counter-intuitively) executed before the loop, yet I need it run immediately at start-up then subsequently delay. Similar SO posts advised a Flow Control Action, however the Pause doesn't actually pause for me.
Others suggest adding a Constant Timer child to Flow Control, but it's utterly ignored. In both cases, the csv rows execute repeatedly with no delay at all.
Has anyone got a recipe for this: Process full csv file every few hours?
Simple to say, strangely hard to do.
My setup: The 'CSV Data Config' uses 'Recycle on EOF':True 'Stop thread on EOF':False. Flow Control Action has 'Pause' Duration: 0 with the child timer set to the desired delay.
Thank you.
* please don't ask why, just assume I truly want this.
Flow Control Action, however the Pause doesn't actually pause for me.
This is kind of weird as it does work and introduces the pause when the thread reaches the sampler.
See the below image, with the Flow Control Action sampler disabled JMeter runs requests as fast as it can and when I enable it JMeter runs requests each 2 seconds according to the configured delay
With regards to "counter-intuitively" behaviour:
As per Timers documentation:
Note that timers are processed before each sampler in the scope in which they are found; if there are several timers in the same scope, all the timers will be processed before each sampler.
Timers are only processed in conjunction with a sampler. A timer which is not in the same scope as a sampler will not be processed at all.
To apply a timer to a single sampler, add the timer as a child element of the sampler. The timer will be applied before the sampler is executed. To apply a timer after a sampler, either add it to the next sampler, or add it as the child of a Flow Control Action Sampler.
Timers also obey JMeter Scoping Rules
I want my simulation to stop as soon as a specific condition in the code is met. By 'stop' I mean it should pause the simulation as if I pressed stop button in the simulation window. So that I could continue the simulation with a slower speed from this moment.
Is there a way to do it from the module code?
There is no API for managing the GUI's run state. The reason is, that you can run the simulation also in Cmdenv without recompiling the code and it's not possible/makes no sense to pause a simulation in Cmdenv.
You can however do a trick, because the simulation is repeatable:
Add some code that prints out the event number when the specific condition occurred.
Run the simulation and note the event number it prints out when the simulation is run.
Now start the simulation again (with the same parameters) but use the "Run until... / Event number" and specify the event number where the GUI should stop.
The alert() method is very convenient to implement #Rudi trick.
In GUI (Run, Fast, and Express) alert() pauses the simulation, shows a message box with own text, waits for user reaction, and then continues the simulation in the same mode. In Cmdenv it shows a text in console without pausing a simulation.
Here is a sample code that prints current event number using this method:
char text[128];
sprintf(text,"Event number: %lld", getSimulation()->getEventNumber());
getSimulation()->getActiveEnvir()->alert(text);
After learning this event number one should do what #Rudi has proposed in the last bullet.
Can I perform a test that will stop in some step, and after I perform something manually in my system I will tell Jmeter to resume running the test?
is it possible in JMeter to pause a test in the middle and then to resume it?
I don't know about out of the box solution in JMeter, so you need to add such logic yourself.
For example you can do a While controller with a variable set to true at start, inside loop read from file until it's value is false and then exit loop and resume test. You can even use StringFromFile function as ${__StringFromFile(flagResume.txt,,,)}
In your manual operations add to file the value false, and then the JMeter test will resume.
What is the nature of the task you need to do manually? I'm pretty much sure that it is doable via JMeter itself, JMeter Plugins or Groovy Scripting.
If I'm wrong or you have a very specific scenario one of possible solutions would be adding Constant Throughput Timer to your Test Plan and define desired Requests per Minute rate using JMeter Property via __P() function
Whenever you need to "stop" the test you can set the "throughput" property to 0 using i.e. Beanshell Server
Control: Okuma OSP-P200L
Machine: LB3000
API: 1.15.0.0
I need to get the cycle time for a part program in an Okuma Lathe using the THINC API. The help file mentions a cycle complete method:
public bool CycleComplete(
MachineSideEnum enMachineSide )
But I'm not finding any way to detect a cycle start.
Any ideas?
Another possible approach is to use the CmachingReport.GetMachiningReports method. It returns an ArrayList of the CMachining class which has a property called OperatingTime. This is a cumulative timer representing actual time from start to finish each time the program is run.
You can calculate the average cycle time for a particular program by dividing the OperatingTime by the NumberOfWork property. Doing it this way would give you some flexibility in case the app isn't running or you don't want to poll.
Like AppFzx said, you'd have to poll.
Have user start the application, then start their part program.
Your application will need to poll GetProgramRunningState() (not faster than 100ms interval!) to see when the part program starts.
Then poll CycleComplete() to see when it finishes.
On that thread though, events are an interesting idea for future API releases...
Currently, I call DoEvents in order to check if Button Foo in Form Bar has been clicked. This approach works but it takes too much processing power, delaying the program.
I believe that the delay could be reduced if I could only check if Button Foo has been clicked, instead of all the other forms that DoEvents has to go through.
Any ideas on how can I check if Button Foo was clicked?
VB6 was not really designed for what you seem to be doing (some sort of long-running straight-line code that does not exit back to give the message loop control). Normally such a task would be delegated to a worker thread, and in VB6 this means some external component implemented in C++ most of the time.
There are only a very few kinds of approaches to take to do this for your ad-hoc logic:
Hacks creating separate threads via API calls, not very reliable in VB6 for a number of reasons.
A tricky thread-per-object ActiveX EXE implementing a class to handle your long-running workload.
A separate non-interactive worker process to be run and monitored by your GUI program.
That's pretty much it.
The prescribed method of doing this sort of thing is described in the VB6 documentation. You break your long-running loop up and invert the logic into a repeatable "quantum" of work (like n iterations of your processing loop), and maintain the state of your workload in Form-global data. Then you use a Timer control with its interval set to 1 or 16 (hardly matters, they normally take at least 16ms to trigger) and run your workload quantum within its event handler.
So if you simply had a loop that currently iterates 100,000 times doing something you might break it up so that it runs 500 times for each Timer tick. The quantum size will probably need to be tuned based on what is done within the loop - 500 is just a value chosen for illustration. You'll want to adjust this until it leaves the UI responsive without starving your background workload too much (slowing completion down).
If your code is heavy enough to not call DoEvents or just finish running periodically, then your app won't even know the button has been pressed. The DoEvents call allows windows, and your application to catch up on all notifications.
The correct way to resolve this is a worker thread (see this article on how to do something like this in VB6) but failing that, a periodic DoEvents is required and in turn, some re-entrancy blocking on the call into the long running code.