Creating components – Speed detector – Part 2

Continuing from last week, the speed detector now requires external connections for the user to configure operation. By capturing the value of the property pins created for each speed detector, and assigning this to the beam breaker components within the speed detector component, we can achieve this. (For reference, this was covered in an earlier post here)

Now that the pinchange macro will callback successfully on shapes breaking the beam breakers, we can edit the flowchart and see its effects.

The macro, when called, needs to start a timer; if a timer hasn’t already been started when the first beam breaker is triggered. Only when a timer has been started, and the first beam breaker has been broken, should the program be allowed to act upon the second beam breaker being broken.

Using a byte to store a value for the state that the program is in we can achieve this. State=0 indicates the program is awaiting the first beam breaker to break, and State=1 indicates the second beam breaker is waiting to be broken.

When the first beambreaker is broken, the timer is started, with an interval set by the user. Every “Timermultiple” milliseconds, will the EV_timer macro be called back. Global variable, “timerval” counts these iterations.

When the second beam breaker is broken, the relevant values for calculating the speed are displayed on the dash, and are then calculated.

This value is then passed to the update display macro.

Update_display is very simple in that it just displays a value passed to it with a text concatenation.

Similarly, the Ev_timer callback is just as simple in that when the timer reaches the time set for it to measure, it is required to start again and measure the next instance of that time. This loop stops when the second beabreaker is broken, and the System.TimerStop macro is called.

Finally, to test the component, in the main macro, there is a short program to move a shape along the plane through the beam breakers. When viewing this macro from within flowcode, just hit the play button. Varying the delay between movements of the shape will speed up and slow down the movement.

Results from varying the Timermultiple value give results that skew when set to a value of less than ~20. Such low latency brings other computations into consideration and becomes inconsistent with expectations.

The Flowcode file for this component is attached here; Speed det pt2. Next week I shall cover a pre-existing component that uses the point cloud component to model a torus in Flowcode!

6,084 total views, 1 views today