0

I will have 4 hardware data acquisition units connected to a single control PC over a hard-wired Ethernet LAN. The coding for this application will reside on the PC and is entirely Python-based. Each data acquisition unit is identically configured and will be polled from the PC in identical fashion. The test boxes they are connected to provide the variable output we seek to do our testing.

These tests are long-term (8-16 months or better), with relatively low data acquisition rates (less than 500 samples per minute, likely closer to 200). The general process flow is simple, too. I'll loop over each data acquisition device and:

  • Read the data off the device;
  • Do some calc on the data;
  • If the calcs say one thing, turn on a heater;
  • If they say anything else, do nothing;
  • Write the data to disk and file for subsequent processing

I'll wait some amount of time, then repeat the process all over again. Here are my questions:

  1. I plan to use a while TRUE: loop to start the execution of the sequence I outlined above, and to allow the loop to be exited via exceptions, but I'd welcome any advice on the specific exceptions I should check for -- or even, is this the best approach to take AT ALL? Another approach might be this: Once inside the while loop, I could use the try: - except: - finally: construct to exit the loop.
  2. The process I've outlined above is for the main data acquisition stuff, but given the length of the collection period, I need to be able to do other things as well: check the hardware units are running OK, take test stands on and offline as required, etc. These 'management' functions ar distinct from the main loop, so I'd like to keep them distinct. Should I set this activity up in separate threads within the same script, or are there better approaches?

Thanks in advance, folks. All feedback is welcome!

Red Spanner
  • 149
  • 10
  • When you say "allow the loop to be exited via exceptions", do you mean a way to kill the script cleanly? Or handling various exceptions that your program may generate, gracefully? – jdi Aug 28 '12 at 18:59
  • Actually, both -- I want an operator to be able to shut down the program cleanly, but also if something unexpected comes out of the gear or the code, I'd like that too, so we can figure out the problem. – Red Spanner Aug 28 '12 at 19:04

2 Answers2

2

I'm thinking that it would be good for you to use client-server model

It would be nicely separated, so one script would not affect the other - status check / data collecting

Basically what you would do it to run server for data collecting on the main machine, which could have some terminal input for maintenance (logging, gracefull exit etc..) and the data collecting PC would act like clients with while True loop (which can run indefinetly unless killed), and on each of data collecting PC would be server/client (depends on point of view) for status check and that would send data to MAIN pc where you would decide what to do

also if you use unix/linux or maybe even windows, for status check just use ssh to the machine and check status (manually or via script from main machine) ... depends on specific needs...

Enjoy

Lu.nemec
  • 484
  • 6
  • 10
1

You may need more than one loop. If the instruments are TCP servers, you may want to catch a 'disconnected' exception in an inside loop and try to reconnect, rather than terminating the instrument thread permanently.

Not sure about Python. On C++, C#, Delphi, I would probably generate the wait by waiting on a producer-consumer queue with a timeout. If nothing gets posted, the sequence you outlined would be repeated as you wish. If some of that other, occasional, stuff needs to happen, you can queue up a message that instructs the thread to issue the necessary commands to the instruments, or disconnect and set an internal 'don't poll, wait until instructed to reconnect and poll again' flag, or whatever needs to be done.

This sort of approach is going to be cleaner than stopping the thread and connecting from some other thread just to do the occasional stuff. Stopping/terminating/recreating threads is just best avoided in any language.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • The DAQ hardware has some "smarts" -- I understand they can work over TCP or UDP, though TCP is recommended. Each DAQ box has a class defined on top of the network, so it looks after all the low-level networking, throwing an exception when there is a problem. I'll have to ponder on your idea about producer/consumer queuing to serve either a collection process or a management process. That's an interesting idea... – Red Spanner Aug 28 '12 at 20:10