10-08-2015 01:44 PM
@Hooovahh wrote:
I don't think there is a multi-quote option, but once you hit reply, hit the Quote button on the upper right of the text box to plop down what they said, like this.
@Vasilich2004 wrote:
When system would be a little complicated - centralization is bad idea.
I would vote for centralization, it might make things more complicated, but you get code that is more manageable, extensible, modular, and probably more reusable.
Great!!! I was able to reproduce 😉
I doubt because central part doen't have any real input. Good example when central part provides useful virtual input is DNS server in network.
It is always good to have self-syncronization on correct level. In another case system could come to the multi-dimension matix in top levle and would be really hard to control. Let take 2 dimention matrix and image that A1 is friend of B2, C3; B2 is friend of B1,B3; etc.
10-08-2015 02:03 PM
@crossrulz wrote:
@Vasilich2004 wrote:
To crossutz:
===========
... I would use the non-reentrant VI approach to do the write and read process.
==========
and in case of 10 or 100 pieces of the same devices in system performance will drop ... 😉
Over RS-232, I doubt we are dealing with that many instruments. And I made that comment based on the understanding that this is the only instrument being used. It is simple and works well. Yes, it does lack scalability, but it is simple for newbies to create.
many
"Many instruments" and "simple" are not coreect arguments. Arguments are:
- library works always
- library provide the best performance
I showed the simplest example to explain the issue because I need to use device which has instr. drivers in LabVIEW. Again I need to write my low level library code for stage that 3 dimension stage works correctly.
10-08-2015 02:03 PM
Thank you everybody for fast responses!
Have a great day!
10-08-2015 03:45 PM
@Vasilich2004 wrote:
To RavensFan:
=============
You should centralize all serial port communication for a given port in a single loop or subVI. Then use queues to send data back and forth to that loop.
============
When system would be a little complicated - centralization is bad idea.
No, when you have a system that fails to work properly because you have something scattered all over the place, then not centralizing your communication is a bad idea.
10-16-2015 11:14 AM
@RavensFan wrote:
@Vasilich2004 wrote:
To RavensFan:
=============
You should centralize all serial port communication for a given port in a single loop or subVI. Then use queues to send data back and forth to that loop.
============
When system would be a little complicated - centralization is bad idea.
No, when you have a system that fails to work properly because you have something scattered all over the place, then not centralizing your communication is a bad idea.
Similar example is network switch and computers behing it. At first, there are protocols which setup switch automaticly-invisible which wouldn't work with Serial port server for one device type. At second, switch backplace is, as minimum, 10x faster than network (that is discussable). Make sense?
Rule is next each level must defense on its level.
Also I suggest to look on real distributed control system, like accelarators.
10-16-2015 11:05 PM
@Vasilich2004 wrote:
Similar example is network switch and computers behing it. At first, there are protocols which setup switch automaticly-invisible which wouldn't work with Serial port server for one device type. At second, switch backplace is, as minimum, 10x faster than network (that is discussable). Make sense?
Rule is next each level must defense on its level.
Also I suggest to look on real distributed control system, like accelarators.
I'm sorry, but none of what you just said makes any sense to me. It seems like you are just pulling terminology from multiple places and trying to equate that with how a single serial port protocol works which is actually pretty ancient technology on a PC.
10-17-2015 12:49 PM
@RavensFan wrote:
@Vasilich2004 wrote:
Similar example is network switch and computers behing it. At first, there are protocols which setup switch automaticly-invisible which wouldn't work with Serial port server for one device type. At second, switch backplace is, as minimum, 10x faster than network (that is discussable). Make sense?
Rule is next each level must defense on its level.
Also I suggest to look on real distributed control system, like accelarators.
I'm sorry, but none of what you just said makes any sense to me. It seems like you are just pulling terminology from multiple places and trying to equate that with how a single serial port protocol works which is actually pretty ancient technology on a PC.
Network swtich = serial port server; computers = serial ports ... if it wouldn't help to improve vision then maybe meeting with glass of wine or vodka 😉
10-17-2015 01:15 PM
10-17-2015 01:31 PM
Take list of paper, draw 2 structures : server/application - serial ports and switch - computers. Looks the same?
Write functionality which was suggested for server/application. Find how it is solved in switch.
Is it possible to repeat in server/application? Probably, yes. How much effort?
10-17-2015 02:55 PM