Should there be a subforum „Lazarus for measurement and automation"?

[CM630]

IMHO, it would be nice if a subforum (or whatever it is called) „Measurement and automation".
We could discuss there issue related with DAQs, DMMs, signal processing, file formats, etc.

[taazz]

I think that the audio and video sub forum can serve for that purpose it has a low enough traffic as it is.

[wp]

To be honest, if I were looking for a question on instrumentation and data aquisition I would never get the idea to peek into "audio and video"...

[Rails]

To be honest, if I were looking for a question on instrumentation and data aquisition I would never get the idea to peek into "audio and video"...

My thoughts exactly.

[taazz]

I disagree, but that can be fixed with a simple name change of the sub forum.
In any case audio and sampling (aka acquisition sample rate) goes hand in hand in most cases because audio is the most common acquisition area that every one has an interest in, even if that interest is only replaying existing data. That's why I proposed to use that sub forum in the first place. Having multiple inactive sub forums will have a negative effect overall, because it makes it harder to choose the correct sub forum to ask a question. As it is now most people will simple post a question on general regardless if there is an appropriate sub forum to post in and in some cases they will post at the wrong general sub forum as well.

[BigChimp]

Agreed with taazz.

[wp]

@taazz: I agree with the point that too many subforums are not good, in particular if the structure extends over several levels. And in fact, I have always been unhappy that the large Graphics subforum has been put underneath "Graphics and Multimedia" recently because the forum of my primary interest, TAChart,  is now no longer visible on the main page.

I do not agree that data aquisition and multimedia are the same thing. I really would not expect an answer to topics such as the National instruments headers (http://www.lazarus.freepascal.org/index.php?action=post;topic=21227.0;last_msg=123945) in the same dedicated forum which discusses how to write an mp3 player. If these topics have to be in the same folder they should be in "General", in particular, because it is to be expected that there will not be much activity in the "Measurement / Data aquisition" forum.

[Rails]

 
In any case audio and sampling (aka acquisition sample rate) goes hand in hand in most cases because audio is the most common acquisition area that every one has an interest in, even if that interest is only replaying existing data.

If I had to guess, I would say home automation would be the most common area. Both my home heating and cooling system and my alarm system have data ports. That seems to be the "new normal" these days. Either one lends itself well to an application developed with Lazarus. In fact, I have plans to write a logger for my heating and cooling system.

 

[eny]

Could be interesting (I'm a hobby PIC programmer myself).

But from a FPC/Lazarus perspective it's normally not that complex. Just implement some way of communicating with an external device via COM, USB, TCP/IP etc. and that's it. Whether you talk to a DMM, PIC, AVR or whatever apparatus, communication all works the same way. Just different data.

After the communication with a device is set up it all depends on the functionality of the application.
And for questions about that there are probably enough area's in the forum.

[jwdietrich]

I generally agree with wp and Rails, but I would prefer to name the subforum "Hardware and Robotics".

[eny]

I generally agree with wp and Rails, but I would prefer to name the subforum "Hardware and Robotics".

Sounds more like an electronics forum:
http://www.circuitsonline.net/forum/section/21
http://www.edaboard.com/
http://www.protonbasic.co.uk/forum.php
http://www.mcuhobby.com/news.php

[CM630]

Hardware and Robotics sound like using a solder-pen.
IMHO, it would better fit in "Graphics and Multimedia", if it is renamed to "Graphics, Multimedia, Measurement and Automation"
Reasons:
  - I found TChart essential for displaying oscillograms.
  - You could you use an audio adapter to take oscillograms.
  - I am considering to use FLAK or other lossless codec to store data.
  - Audio tracks are oscillograms, and they might share some manipulation features with other signals.

On the other hand:
- Graphics and multimedia are subjects of more common issue
- RS232, GPIB etc. communication does not fit it.

But the first point before putting a "Measurement and Automation" section somewhere is if it shall be put somewhere at all. If nobody but me is interested, then it makes no sense.

Maybe there could be a "Rare issues/ Low interested" section where things like that can be put.
Or maybe "Other" could have subsections.

[taazz]

To be frank I'm interested on the subject it is an area that I have no experience in and it is very interesting to me. If you can provide emulators I would surely spend time on whatever problem you might have or want a second opinion. It will be a good opportunity for me to learn and have some fun. At this point I would suggest to use the "graphics and multimedia" category which is empty for automation type of questions and if there is enough traffic then we can ask for a specific category.

of course since I am not a moderator on this forums I would like some one that has the authority to confirm that we can act as suggested.

[CM630]

Currently I have problems with TAChart mostly.
Also, I do not know how to handle this issue, in fact I did not try yet.

So probably I have more things to say, than to ask.
As far as emulators for NI and Measurement Computing emulators are concerned, they come with drivers: for NI and for MCC. I recommend using a FTP client for downloading the MCC stuff).
Unfortunately, you cannot do much with emulators, especially the NI one is very close to nothing.

[Laksen]

I think it could be fun with a more hardware oriented subforum. We could just call it "Hardware related". We get lots of questions about RS232 and parallel ports and such already.

paskal, as the guy in the thread you linked suggests you should use dynamic linking.

You probably have something like this now:

Code: [Select]

unit somelibrary;

interface

const
{$ifdef windows}
 libname = 'nidaq.dll';
{$endif}

function nisomething(test: longint): longint; stdcall; external libname;
procedure nisomething2(test: longint); stdcall; external libname;

implementation
end.

You should instead use something like this. Then you can just test on SupportsSomelibrary whether it could find the DLL:

Code: [Select]

unit somelibrary;

interface

const
{$ifdef windows}
 libname = 'nidaq.dll';
{$endif}

type
 tnisomething = function(test: longint): longint; stdcall;
 tnisomething2 = procedure(test: longint); stdcall;

var
 SupportsSomelibrary: boolean = false;

 nisomething: tnisomething;
 nisomething2: tnisomething2;

implementation

uses dynlibs;

procedure LoadDll;
begin
   h := LoadLibrary(libname);
   if h <> NilHandle then
   begin
      SupportsSomelibrary := true;
     
      pointer(nisomething) := GetProcedureAddress(h, 'nisomething');
      pointer(nisomething2) := GetProcedureAddress(h, 'nisomething2');
   end;
end;

initialization
   LoadDll;

end.