Hi JKSH,
If I were starting a new application, I would use Express VIs over function blocks. Here are a list of things to consider when choosing:
- By default, function blocks are asynchronous. They execute on the rising edge of the 'execute' input and are done when the 'done' output goes high. They do not block and a function block architecture will almost always involve calling the same function blocks over and over in a loop. You control the execution flow with the 'execute' and 'done' input and output. Express VIs, on the other hand, are by default synchronous. They do not have an 'execute' input and instead begin execution as soon as they are called. They also block until finished. Express VIs can be converted to asynchronous by right clicking on them and changing the 'timing model.' When you change the timing model to asynchronous, the Express VI will now act exactly like a function block.
- In general, you should never mix asynchronous and synchronous APIs. Your entire application should be one or the other. While it is possible to safely have both synchronous and asynchronous calls, you have to be very careful and really know what you're doing.
- In my experience, writing simple applications is easier with a synchronous API and more complex applications are better suited for an asynchronous API. Since synchronous calls are blocking, you need more loops in your application and it can become difficult to maintain.
- There is also the property/invoke node API, upon which both function blocks and Express VIs are built. You can right click on either a function block or Express VI and convert it to a subVI to see the underlying code. While function blocks and Express VIs can be nice to work with, sometimes you need the lower level control that is offered by the property and invoke nodes.
I looked at your other post and it looks like you are encountering one of the subtleties of asynchronous calls. In point 1 above, I mentioned that function blocks are rising edge sensitive on the execute line. In both your modified example and the original example, the 'Update Buffer' function block is executed when the 'space available' becomes greater than or equal to the 'Size of the Contour Data.' In the original example, the table size is 40, but in your example, it is 100. Let's trace the flow through the example:
- We don't do anything in the first iteration since we don't see a rising edge on the 'execute' signal of 'Initialize Buffer' until the second iteration.
- At the beginning of the second iteration, we initialize the table with 20 points, leaving 20 spaces available. This function block may take more than one iteration to complete, so the loop may run several cycles before the 'Done' output is true. When this happens, the next block executes.
- Next we start the contour move. No point gets taken from the buffer yet; that happens in in the non user code portion of the scan.
- Next we see that there are 20 spaces available,, so we add 20 more points to the buffer, leaving us with 0 spaces available. This means that in the next iteration of the loop, the 'execute' signal of the 'Update Buffer' function block will go false. This is critical to the operation of the example.
- Since there is no abort called, we loop back around.
- Every scan, SoftMotion is taking one point from the buffer. Eventually, the number of points available will climb back to 20. When this happens, the 'execute' input will toggle from false to true on the 'Update Buffer' function block and 20 more points will be added to the buffer. This cycle continues until you stop.
So what was wrong with your modification? You made the table size 100 points. If you look at the steps above, you'll see that in the example, we put 40 points into the buffer before taking any points out. If you increase the table size to 100, that means that there will be 60 spaces available. However, 60 is still greater than 'size of contour data' (which is 20) and so the 'execute' input of the 'Update Buffer' function block never goes false; we always have more space available than the 'size of contour data.' Since 'execute' is rising edge sensitive, we're never actually putting new data into the buffer and therefore you only get out the two cycles that you originally put in. I agree that this is tricky, but it is exactly as function blocks are supposed to operate and is definitely something to think about when using the asynchronous API.
Thanks,
