06-14-2018 09:42 AM
@RTSLVU wrote:
I find a "State Machine" architecture works for 99% of the programs I write.
Ugh! While it's generally true that 'a <fill-in-the-blank-with-anything> architecture> can work in 99% of your programs', anyone who uses the same architecture 99% of the time is probably writing a lot of poor code.
06-14-2018 09:44 AM
@paul_cardinale wrote:
@RTSLVU wrote:
I find a "State Machine" architecture works for 99% of the programs I write.
Ugh! While it's generally true that 'a <fill-in-the-blank-with-anything> architecture> can work in 99% of your programs', anyone who uses the same architecture 99% of the time is probably writing a lot of poor code.
Meh... 99% of my programs are data logging and instrument control.
A state machine is the perfect fit unless I need high speed acquisition, then it's a producer/consumer, but the consumer loop will probably still have a state machine inside it. 😛
06-14-2018 10:48 AM
@paul_cardinale wrote:
@RTSLVU wrote:
I find a "State Machine" architecture works for 99% of the programs I write.
Ugh! While it's generally true that 'a <fill-in-the-blank-with-anything> architecture> can work in 99% of your programs', anyone who uses the same architecture 99% of the time is probably writing a lot of poor code.
I would say that is only strictly true if 99% of your projects are 99% different from each other. I would say that 99% of the time, generalization isn't the best thing. 😉
06-15-2018 09:37 AM
@billko wrote:
@paul_cardinale wrote:
@RTSLVU wrote:
I find a "State Machine" architecture works for 99% of the programs I write.
Ugh! While it's generally true that 'a <fill-in-the-blank-with-anything> architecture> can work in 99% of your programs', anyone who uses the same architecture 99% of the time is probably writing a lot of poor code.
I would say that is only strictly true if 99% of your projects are 99% different from each other. I would say that 99% of the time, generalization isn't the best thing. 😉
No sense reinventing the wheel.
06-15-2018 09:40 AM
@cy... wrote:
@RTSLVUadding a timeout on those subVI may improve the responsiveness of the abort.
also wondering why: sequentially? race conditions?
Over use of sequence structures is a huge sign that the programer did not understand the "Data Flow" concept LabVIEW programming is based on.
07-20-2018 06:59 PM
Thanks for the replies everyone. For some reason it started mysteriously working again. I'll return to this if there are any more problems.