style of code to use for next step

[rayclout]

Hello All

With regards to the attached piece of code, I would appreciate some suggestions as to how to proceed.

As you can see, the vi has quite a number of serial interfaces. These interfaces are connected to indivdiual motor control cards (apart from the SLCD display interface). I have no other choice in regards to using these serial interfaces....it's just an unfortunate necessitation.

The operation of the vi is this:

The SLCD display serial port is polled for a number to arrive from a HID keyboard as pressed by an operator. The operator will hold down the key (which is typematic) until satisfied that a visual observed position has been achieved. The number of the key is sent to the serial port from the HID on a regular timed basis.

Depending on the number arriving, a case structure is selected and subsequently a command is written out on the appropriate serial port (yes.....I know the FP shows all the com ports are set to 2.....don't worry about that....it's in hand).

The code works for the aplication it is built for.

Now, I would like to expand it so that a series of pulses coming in on the port named Phidget Counter can be counted and recorded (from the pulses positional information will be gleaned). At this point in time, I now think it necessary to give some serious consideration into changing the coding stlye.

My question(s) are:

1. To add the pulse functionality functionality, would it be best to revert to using the producer/consumer architecture?

2. Would it be best to move all the serial port activity to the producer loop of the producer/consumer architecture, and leave the command coding in the consumer loop?

3. Is there a better way of doing this than the p/c architecture (or for that matter what has been done so far).

Please, to those so inclined, I'm not offering up my questions as a forum for ridicule, or did I do this?...did I try that?....did I search this?...did I search that?....is this homework?......you get the picture. The answers by the way are Y,Y,Y,Y,N.

I am happy to receive genuine constructive critiques.....and willing to employ any suggestions that are offered.

Thank you in advance

Ray

[MoReese]

Use shift registers on your error clusters so errors will get passed on to the next iteration or you can OR your error cluster boolean element with the Stop button for your stop terminal, this way the loop will cease on error.

I'll mention the obvious:  You should have thought about the archetecture at the beginning.  But that said, I would recommend always using the Producer/Consumer archetecture, in most instances.  It's hard to go wrong with it.  The biggest decision will be either a Data or Event based archetecture.  That depends on your user interface.  In this case, a data archetecture might be better.  In applications where the operator is accessing FP controls and features on a regular basis, an Event based design would be better.

I would leave your data processing and coding in the Consumer loop.  That's what it's for.  The Producer should have very little to do, except wait for data and queue it when it is received.

Use the SLCD data to trigger the Producer Loop to queue the data.  Your main case structure will than be in the Consumer loop.

What is the frequecy of these pulses?

[rayclout]

Hello Reese

Thanks firstly for your interest.

I have actually produced a vi, as you explained below, using p/c. Given that the producer has very very little to do, I figured it might be just a waste of coding time and went with what was attached.

The pulses are of the order of 4pps.....very slow in fact.

Where would the pulse counter code be placed (or split) in the p/c loops?

Regards

Ray

[rayclout]

Hello Again Reese

I've attached my code for the p/c style that I had first tried.

One thing.....In my state machine example I was using the no bytes at port to trigger the case structure.

I'm not sure how to get this information from the producer loop to the consumer loop....could you explain how I might do this.

I also like your method of stopping the vi with the error cluster connected to the stop button (should this be for both loops?), and would appreciate it if you could also explain further in detail.

Thanks again

Ray

[MoReese]

---

@rayclout wrote:

Hello Again Reese

I've attached my code for the p/c style that I had first tried.

One thing.....In my state machine example I was using the no bytes at port to trigger the case structure.

You can still do this with the P/C.  When data is available, you can trigger the queue with a boolean and pass the number of received bytes to the Consumer loop, or just a constant, it doesn't really matter, because your consumer loop will activate, at which point you can read data in from the serial port and perform extra processing.  Another option would be to receive your data in the Producer loop and pass it to the Consumer loop for processing, which may be a better solution here.

I'm not sure how to get this information from the producer loop to the consumer loop....could you explain how I might do this.

You would do this using queues.  Any data you want to pass to the consumer loop must be passed to the queue.

I also like your method of stopping the vi with the error cluster connected to the stop button (should this be for both loops?), and would appreciate it if you could also explain further in detail.

Yes, wire both loops to the error cluster, except, in the Producer loop, if you still want a mechanism for stopping the loop manually, OR the error cluster with your Stop button control.

Thanks again

Ray

---