| ID |
Date |
Author |
Topic |
Subject |
|
2280
|
29 Sep 2021 |
Richard Longland | Bug Report | nstall clash between MIDAS 2020-08 and mscb | Thank you, Stefan.
I found these instructions under
1) The changelog: https://midas.triumf.ca/MidasWiki/index.php/Changelog#2020-12
2) Konstantin's elog announcements (e.g. https://midas.triumf.ca/elog/Midas/2089)
I do see reference to updating the submodules under the TRIUMF install
instructions
(https://midas.triumf.ca/MidasWiki/index.php/Setup_MIDAS_experiment_at_TRIUMF#Inst
all_MIDAS) although perhaps it can be clarified.
Cheers,
Richard |
|
96
|
20 Nov 2003 |
Renee Poutissou | | cannot shutdown defunct clients | Indeed the ODB command "cleanup" really works. I have used it several
times with the TWIST DAQ and regularly with the BNMR/MUSR setups where
we have these stubborn clients (ie feepics) that do not want to shutdown
cleanly.
But there is one problem with "cleanup". It has a hardwired timeout of
2 seconds. This is a problem for tasks like lazylogger which set a timeout
of 60 seconds when moving the tape. So BEWARE, if you issue the "cleanup"
command, it might kill some clients who have setup their timeout to longer
than 2 seconds.
I have asked Stefan to change this before. He said that, to be effective,
the timeout value used for "cleanup" has to be rather short.
One possibility, would be to allow for a user entered "cleanup" timeout.
The default could stay at 2 seconds.
> > Have you tried a "cleanup" in ODBEdit?
>
> Nope. Will try next time...
> |
|
11
|
11 Mar 2004 |
Renee Poutissou | | Creation of secondary Midas output file. | Jan ,
Do you need to log this stage 1 output? If not, you would use the
eventbuilder mechanism to create your stage 2 events.
I use the eventbuilder mechanism with success for my TWIST experiment.
Renee |
|
171
|
02 Nov 2004 |
Renee Poutissou | Info | Event Builder info in mhttpd Status page | Information about the Event Builder statistics has been removed from the
Status page in mhttpd. I heard from Pierre that this information might
be redundant when using the new Event Builder format???
For the TWIST experiment, we are running and cannot change on the fly
to a new format Event Builder. It is very important for us to show the users
the rates and statistics coming out of the EventBuilder. I had to put this
piece of code back in mhttpd.
Can I put it back in the distribution? or do I have to put a special TWIST flag?
or do I have to keep reinserting this every time there is an update to mhttpd.c?
At the moment, TWIST is generating a couple of updates/week to mhttpd.c |
|
543
|
17 Dec 2008 |
Renee Poutissou | Bug Report | Overflow on "cm_msg" command generates segfault | The following error has been reported to me by T2K colleagues:
When using "odbedit -c "msg my_message", the following behavior
has been observed depending on the length "n" of the message.
1) n < 100 All is well
2) 100 <= n < 245 Log not written but exit code = 0
3) 245 <= n < 280 Error: "Experiment not defined" and exit code = 1
4) 280 <= n Error: "Cannot connect to remote host" and exit code = 1
Also, when logging from compiled C code - when messages reach some magic length
the MIDAS client sending them segfaults.
Please fix |
|
558
|
23 Jan 2009 |
Renee Poutissou | Info | Subrun scheme implemented | Hi Stefan,
My colleague Tobi Raufer (tobi.raufer@stfc.ac.uk) has tested this new implementation and
sent me the following questions:
-------- Original Message --------
Subject: Re: [Fwd: [Midas] Subrun scheme implemented]
Date: Fri, 23 Jan 2009 01:52:37 +0000
From: Tobias Raufer <tobi.raufer@stfc.ac.uk>
To: Renee Poutissou <renee@triumf.ca>
Hi Renee
I have tested the new subrun functionality a bit more and I have two observations. First, it seems to work on a basic level, i.e. subruns are created, which are equal in size. However, I can't relate their size to the byte limit set in the ODB.
Here is an example. The settings in the ODB are the following:
[local:testExp:S]/>ls /Logger/Channels/0/Settings/
Active y
Type Disk
Filename run%05d_%02d.mid
Format MIDAS
Compression 0
ODB dump n
Log messages 0
Buffer SYSTEM
Event ID -1
Trigger mask -1
Event limit 0
Byte limit 0
Subrun Byte limit 10000
Tape capacity 0
Subdir format
Current filename run00005_07.mid
As you can see, I set the subrun byte limit to 10000. Here are the subrun files which were created:
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_00.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_01.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_02.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_03.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_04.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_05.mid
-rw-r--r-- 1 raufer 32800 Jan 23 01:36 run00005_06.mid
-rw-r--r-- 1 raufer 4960 Jan 23 01:36 run00005_07.mid
The file size seems to be 32800 bytes. Any idea what's going on? I first thought this might have to do with the ODB dump not being accounted for but as you can see from the configuration above, I turned it off for this run.
When I run with the ODB dump on but with the same byte limit, things become even more strange. I get the following sizes:
bash-3.2$ ls -l run00006_*.mid
-rw-r--r-- 1 raufer 53798 Jan 23 01:46 run00006_00.mid
-rw-r--r-- 1 raufer 53804 Jan 23 01:46 run00006_01.mid
-rw-r--r-- 1 raufer 53793 Jan 23 01:46 run00006_02.mid
-rw-r--r-- 1 raufer 53781 Jan 23 01:46 run00006_03.mid
-rw-r--r-- 1 raufer 53781 Jan 23 01:46 run00006_04.mid
-rw-r--r-- 1 raufer 53781 Jan 23 01:46 run00006_05.mid
-rw-r--r-- 1 raufer 53802 Jan 23 01:46 run00006_06.mid
-rw-r--r-- 1 raufer 53833 Jan 23 01:46 run00006_07.mid
-rw-r--r-- 1 raufer 71557 Jan 23 01:46 run00006_08.mid
-rw-r--r-- 1 raufer 20999 Jan 23 01:46 run00006_09.mid
As you can see, now the sizes are larger and they don't even seem to be consistent between the different subruns. Renee, could you forward this to the MIDAS developers?
Thanks much,
Tobi
| Quote: |
The code has been tested in two test environments, but not yet in a real experiment. So please test it before going into production. The modification in mlogger requires SVN revision 4440 of mlogger.c and 4441 of odb.c.
Please note that the lazylogger cannot be used with this scheme at the moment since it does not recognize the subruns. That will be fixed in a future version and announced in this forum.
- Stefan |
|
|
5
|
14 Jan 2004 |
Razvan Stefan Gornea | | Access to hardware in the MIDAS framework | I am just starting to explore MIDAS, i.e. reading the manual and trying
some examples. For the moment I would like to make a simple frontend that
access a portable multimeter through RS-232 port. I think this could help
me understand how to access hardare inside MIDAS framework. Initially I've
started from the MiniFE.c example and tried to initialize the serial port
on run start transition and build a readout loop in the main function. I
know that this is not a full frontend but I was just interested in getting
some experience with the drivers available in the distribution, in this
case RS-232. The portable multimeter is very simple in principle, one just
has to configure the port settings and then send character 'R' and read 14
ASCII characters from the device. Unfortunately I could not understand how
to invoke the driver services so I changed and started again with the
slowcont/frontend.c example. From this example and after reading the "Slow
Control System" section in the MIDAS manual I think that all I need to do
is to define my own equipment structure based on the multi.c class driver
with a single input channel (and replace the null driver with the RS-232).
Here I got stuck. I see from the code source that there is a relationship
between drivers at all levels (even bus) and the ODB but I don't yet fully
understand how they work. Actually for a couple of days now I am in a loop
going from class to device to bus and then back again to class drivers
trying to see how to create my own device driver and especially how to call
the bus driver. It could be that the framework is invoking the drivers and
the user just has to configure things ... up to now I didn't dare to look
at the mfe.c.
Is there a more detailed documentation about slow control and drivers then
the MIDAS manual? What is the data flow through the three layers system for
drivers? What is the role of the framework and what is left to the user
choice?
Thanks |
|
7
|
16 Jan 2004 |
Razvan Stefan Gornea | | Access to hardware in the MIDAS framework | The multimeter device is indeed to simple to use MIDAS but I am just trying
it as a learning experience. The DAQ system to develop involves VME crates
and general purpose I/O boards. The slow control part, especially accessing
the I/O boards seem to me more complex then the VME access. I want to
understand very well the "correct" way of using the MIDAS slow control
framework before starting the project.
I chose the second method and created a meterdev.c driver (essentially a
copy of the nulldev.c) where I changed the init. function and the get
function. I am not sending a "INIT ..." string because for this device it
is useless. In the get function I send a "D" and read my string. I changed
the frontend of the example to have a new driver list (in the first try I
eliminated the Output device but the ODB got corrupted, I guess the class
multi needs to have defined output channels). The output channel is linked
with nulldev and null (I guess this is like if they would not be present).
The result is strange because the get function is called all the time very
fast (much faster then the 9 seconds as set in the equipment) and even
before starting the run (I just put the flag RO_RUNNING).
Thanks for any help |
| Attachment 1: frontend.c
|
//********************************************************************************************
//
// Name: frontend.c
// Created by: Razvan Stefan Gornea
//
// Contents: Slow Control frontend for a portable multimeter
//
// Log: 2004-01-15 14:22
// Writing down initial code.
//
//********************************************************************************************
#include <stdio.h>
#include "midas.h"
#include "class/multi.h"
#include "device/nulldev.h"
#include "meterdev.h"
#include "bus/null.h"
#include "bus/rs232.h"
// globals variables
// frontend name
char *frontend_name = "Slow Control";
// frontend file name
char *frontend_file_name = __FILE__;
// frontend loop
BOOL frontend_call_loop = FALSE;
// frontend display refresh
INT display_period = 1000;
// maximum event size in bytes
INT max_event_size = 10000;
// maximum event size for fragments in bytes
INT max_event_size_frag = 5*1024*1024;
// buffer size in bytes
INT event_buffer_size = 10*10000;
// equipment list
// device drivers
DEVICE_DRIVER multi_driver[] = {
{"Input", meterdev, 1, rs232, DF_INPUT},
{"Output", nulldev, 1, null, DF_OUTPUT},
{""}
};
// equipment list
EQUIPMENT equipment[] = {
{ "Multimeter", /* equipment name */
11, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
EQ_SLOW, /* equipment type */
0, /* event source */
"FIXED", /* format */
TRUE, /* enabled */
RO_RUNNING, /* read when running */
9000, /* read every 9 sec */
0, /* stop run after this event limit */
0, /* number of sub events */
1, /* log history every event */
"", "", "",
cd_multi_read, /* readout routine */
cd_multi, /* class driver main routine */
multi_driver, /* device driver list */
NULL, /* init string */
},
{ "" }
};
// routines
INT poll_event(INT source[], INT count, BOOL test) {return 1;};
INT interrupt_configure(INT cmd, INT source[], PTYPE adr) {return 1;};
// frontend initialization
INT frontend_init()
{
return CM_SUCCESS;
}
// frontend exit
INT frontend_exit()
{
return CM_SUCCESS;
}
// frontend loop
INT frontend_loop()
{
return CM_SUCCESS;
}
// begin of run
INT begin_of_run(INT run_number, char *error)
{
return CM_SUCCESS;
}
// end of run
INT end_of_run(INT run_number, char *error)
{
return CM_SUCCESS;
}
// pause run
INT pause_run(INT run_number, char *error)
{
return CM_SUCCESS;
}
// resume run
INT resume_run(INT run_number, char *error)
{
return CM_SUCCESS;
}
|
| Attachment 2: meterdev.c
|
//********************************************************************************************
//
// Name: meter.c
// Created by: Razvan Stefan Gornea
//
// Contents: Device driver for a portable multimeter
//
// Log: 2004-01-15 14:22
// Writing down initial code.
//
//********************************************************************************************
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include "midas.h"
// globals variables
#define DEFAULT_TIMEOUT 10000 // 10 secondes
typedef struct {
int address;
} METERDEV_SETTINGS;
#define METERDEV_SETTINGS_STR "\
Address = INT : 1\n\
"
typedef struct {
METERDEV_SETTINGS meterdev_settings; // device settings
float *array; // data array
INT num_channels; // number of channels associated with this device
INT (*bd)(INT cmd, ...); // bus driver entry function
void *bd_info; // private settings and data related to the bus driver
HNDLE hkey; // ODB key for bd_info structure
} METERDEV_INFO;
// routines
// initialization function: access the ODB to creates the settings, initializes the variables
// and calls the initialization function of the bus driver
INT meterdev_init(HNDLE hkey, void **pinfo, INT channels, INT (*bd)(INT cmd, ...))
{
int status, size;
HNDLE hDB, hkeydd;
METERDEV_INFO *info;
// allocate info structure
info = calloc(1, sizeof(METERDEV_INFO));
*pinfo = info;
// get handle on current experiment ODB
cm_get_experiment_database(&hDB, NULL);
// create METERDEV settings record
status = db_create_record(hDB, hkey, "DD", METERDEV_SETTINGS_STR); // force the ODB structure to match the METERDEV_SETTINGS C structure
if (status != DB_SUCCESS) {
return FE_ERR_ODB;
}
db_find_key(hDB, hkey, "DD", &hkeydd); // get handle on the DD key in the ODB associated with a certain equipment and device as pointed by the "hkey" handle
size = sizeof(info->meterdev_settings); // get the size of the device settings structure
db_get_record(hDB, hkeydd, &info->meterdev_settings, &size, 0); // load the device settings for the ODB, i.e. ontent of DD key
// initialize the driver
info->num_channels = channels; // define the nmber of channels
info->array = calloc(channels, sizeof(float)); // allocate space for data
info->bd = bd; // set handle on bus driver
info->hkey = hkey; // set handle on the ODB key for the evice driver
if (!bd) { // if handle invalid return error
return FE_ERR_ODB;
}
// call the bus driver initialization routine
status = info->bd(CMD_INIT, info->hkey, &info->bd_info);
if (status != SUCCESS) {
return status;
}
// initialization of device, something like ...
//BD_PUTS("init");
// for this device no initialization string is needed ...
return FE_SUCCESS;
}
// decomission function: free memory allocation(s) and close device(s)
INT meterdev_exit(METERDEV_INFO *info)
{
// call EXIT function of bus driver, usually closes device
info->bd(CMD_EXIT, info->bd_info);
// free local variables
if (info->array) {
free(info->array);
}
free(info);
return FE_SUCCESS;
}
// set channel value
INT meterdev_set(METERDEV_INFO *info, INT channel, float value)
{
char str[80];
// set channel to a specific value, something like ...
sprintf(str, "SET %d %lf", channel, value);
BD_PUTS(str);
BD_GETS(str, sizeof(str), ">", DEFAULT_TIMEOUT);
// simulate writing by storing value in local array, has to be removed in a real driver
if (channel < info->num_channels) {
info->array[channel] = value;
}
return FE_SUCCESS;
}
// set all channels values
INT meterdev_set_all(METERDEV_INFO *info, INT channels, float *value)
{
int i;
char str[1000];
// put here some optimized form of setting all channels simultaneously like ...
strcpy(str, "SETALL ");
for (i=0 ; i<min(info->num_channels, channels) ; i++) {
sprintf(str+strlen(str), "%lf ", value[i]);
}
BD_PUTS(str);
BD_GETS(str, sizeof(str), ">", DEFAULT_TIMEOUT);
// simulate writing by storing values in local array
for (i=0 ; i<min(info->num_channels, channels) ; i++) {
info->array[i] = value[i];
}
return FE_SUCCESS;
}
// get channel value
INT meterdev_get(METERDEV_INFO *info, INT channel, float *pvalue)
{
int status, i;
char str[80];
char ascii_number[5];
// read value from channel, something like ...
//sprintf(str, "GET %d", channel);
sprintf(str, "D"); // request data
BD_PUTS(str);
status = BD_GETS(str, sizeof(str), "\n", DEFAULT_TIMEOUT); // read until getting a cariage return or exit on timeout
for (i = 0; i < 4; i++) { // transfer the number
ascii_number[i] = str[i+4];
}
ascii_number[4] = '\0'; // end of string
*pvalue = (float) atof(ascii_number); // convert from ASCII to float
// simulate reading by copying set data from local array
//if (channel < info->num_channels) {
// *pvalue = info->array[channel];
//}
//else {
// *pvalue = 0.f;
//}
return FE_SUCCESS;
}
// get all channels values
INT meterdev_get_all(METERDEV_INFO *info, INT channels, float *pvalue)
{
// int i;
/* put here some optimized form of reading all channels. If the deviced
does not support such a function, one can call nulldev_get() in a loop
strcpy(str, "GETALL");
BD_PUTS(str);
BD_GETS(str, sizeof(str), ">", DEFAULT_TIMEOUT);
for (i=0 ; i<min(info->num_channels, channels) ; i++)
pvalue[i] = atof(str+i*5); // extract individual values from reply
*/
/* simulate reading by copying set data from local array */
//for (i=0 ; i<min(info->num_channels, channels) ; i++)
// pvalue[i] = info->array[i];
return FE_SUCCESS;
}
// device driver entry point
INT meterdev(INT cmd, ...)
{
va_list argptr;
HNDLE hKey;
INT channel, status;
DWORD flags;
float value, *pvalue;
void *info, *bd;
va_start(argptr, cmd);
status = FE_SUCCESS;
switch (cmd) {
case CMD_INIT:
hKey = va_arg(argptr, HNDLE);
info = va_arg(argptr, void *);
channel = va_arg(argptr, INT);
flags = va_arg(argptr, DWORD);
bd = va_arg(argptr, void *);
status = meterdev_init(hKey, info, channel, bd);
break;
case CMD_EXIT:
info = va_arg(argptr, void *);
status = meterdev_exit(info);
break;
case CMD_SET:
info = va_arg(argptr, void *);
channel = va_arg(argptr, INT);
value = (float) va_arg(argptr, double); // floats are passed as double
status = meterdev_set(info, channel, value);
break;
case CMD_SET_ALL:
info = va_arg(argptr, void *);
channel = va_arg(argptr, INT);
pvalue = (float *) va_arg(argptr, float *);
status = meterdev_set_all(info, channel, pvalue);
break;
case CMD_GET:
info = va_arg(argptr, void *);
channel = va_arg(argptr, INT);
pvalue = va_arg(argptr, float*);
status = meterdev_get(info, channel, pvalue);
break;
case CMD_GET_ALL:
info = va_arg(argptr, void *);
channel = va_arg(argptr, INT);
pvalue = va_arg(argptr, float*);
status = meterdev_get_all(info, channel, pvalue);
break;
default:
break;
}
va_end(argptr);
return status;
}
|
|
270
|
11 Jul 2006 |
Razvan Stefan Gornea | Forum | Tundra Universe CA91C042 | I am not using Midas but I need some help from somebody experienced with VME access using the Tundra Universe, so I thought here I have a chance ...
I have a GE Fanuc 7700 and use the vme_universe driver (ver. 3.3). In the past I programed for a DAQ board using A24/D16. Now I have a new board using A24/MB and I am really last!
So the board has some 64-bit registers and some 32-bit registers (all aligned on 64-bit) and a FIFO to read the main data. After reading the user manual for universe chip and the docs for the driver I am still confused about how things are supposed to work.
First my understanding is that for reading 64-bit I need anyway the multiplex block mode. But nowhere I could find if the multiplex mode supports 32-bit transfers. Should I map two windows on the same VME address range, one for A24/D32 and one for A24/MB? Or read everything with an unsigned long long and cast to unsigned int all 32-bit registers?
Second I don't know how to handle the FIFO which is in the middle of the address range. When the board has a trigger I have to read more than 100000 times this FIFO. If I simply read at the FIFO address 100000 times do I get the VME multiplex block mode (if the window has been mapped with A24/MB address modifier)? How does the chip/driver know not to send the address and just do the data cycle after the first read?
I also had the naive idea to have a master window mapped on the board address range to access all the registers except the FIFO and to create a DMA buffer for the FIFO (FIFO readout is where most of the work is anyway so I guess an advantage is that will free the CPU) but it seems to me that the dma_transfer function in the kernel module increments the address. I don't dare change this since I don't even understand the exact relationship between accesses to the mapped window and what's happening on the VME bus.
Thanks for any help! |
|
598
|
24 Jun 2009 |
Razvan Stefan Gornea | Forum | Frontend and manual trigger question | Hi,
I have a question related to the frontend and I would need some suggestions
about the proper way of doing things in Midas.
I have some CAEN ADC boards and a VME interface and I made a simple frontend
that configures and reads the system and it works great ... Now I would like to
add a feature and it seems to me I am going the wrong way.
I would like to add manual trigger capability and so I added the EQ_MANUAL_TRIG
flag to the "CAEN" equipment type but the problem is that the framework calls
directly the readout function on "Midas manual trigger". To trigger manually the
CAEN ADC's I have to write some registers and therefore I either need to have a
function called before the readout function or be able in the readout function
to know if the call has been triggered by the poll function or "Midas manual
trigger". I tried to check the value *((DWORD *)pevent) but it seems to be a
well defined and meaningful value only when the readout function call is
triggered by the poll function.
So my question is what's the proper "Midas way" of doing this? Should I create a
new equipment which is of EQ_MANUAL_TRIG type and its readout function writes
the registers on the CAEN ADC's to trigger manually the boards? Is there a way
of "mapping" the Midas manual trigger to a "trigger generator function"? Because
I am a little bit confused ... Is the Midas manual trigger on the new equipment
(let's say "Manual trigger manager") going to increment the event ID? Then when
the event is really read through the readout function of the "CAEN" equipment
the event ID is going to be incremented again obviously ...
Thanks a lot,
Razvan |
|
927
|
09 Nov 2013 |
Razvan Stefan Gornea | Forum | Installation problem | Hi,
I run into problems while trying to install Midas on Slackware 14.0. In the past
I have easily installed Midas on many other versions of Slackware. I have a new
computer set up with Slackware 14.0 and I just got the Midas latest version from
https://bitbucket.org/tmidas/midas
Apparently there is a problem with a shared library which should be on the
system, I think make checks for /usr/include/mysql and then supposes that
libodbc.so should be on disk. I don't know why on my system it is not.
But I was wondering if I have some other problems (configuration problem?)
because I get a very large number of warnings. My last installation of Midas is
like from two years ago but I don't remember getting many warnings. Do I do
something obviously wrong? Here is uname -a output and I attached a file with
the output from make in midas folder (GNU Make 3.82 Built for
x86_64-slackware-linux-gnu). Thanks a lot!
Linux lheppc83 3.2.29 #2 SMP Mon Sep 17 14:19:22 CDT 2012 x86_64 Intel(R)
Xeon(R) CPU E5520 @ 2.27GHz GenuineIntel GNU/Linux |
| Attachment 1: output.log
|
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/midas.o src/midas.c
src/midas.c: In function 'cm_transition2':
src/midas.c:3769:74: warning: variable 'error' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'cm_transition':
src/midas.c:4388:19: warning: variable 'tr_main' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'cm_ctrlc_handler':
src/midas.c:4482:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'bm_receive_event':
src/midas.c:7426:22: warning: variable 'pclient' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'bm_push_event':
src/midas.c:7738:22: warning: variable 'pclient' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'bm_defragment_event':
src/midas.c:8382:15: warning: variable 'j' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'rpc_execute_ascii':
src/midas.c:12157:41: warning: variable 'last_param_ptr' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'bk_list':
src/midas.c:13939:13: warning: variable 'size' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'rb_increment_wp':
src/midas.c:14545:19: warning: variable 'old_wp' set but not used [-Wunused-but-set-variable]
src/midas.c: In function 'rb_increment_rp':
src/midas.c:14672:28: warning: variable 'old_rp' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c: In function 'ss_shm_close':
src/system.c:871:11: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/system.c: In function 'ss_shm_protect':
src/system.c:1059:11: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/system.c: In function 'ss_exception_handler':
src/system.c:3410:10: warning: variable 'p' set but not used [-Wunused-but-set-variable]
src/system.c: In function 'ss_set_screen_size':
src/system.c:5961:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/system.c: In function 'ss_directio_give_port':
src/system.c:6426:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/system.c: In function 'ss_directio_lock_port':
src/system.c:6465:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mrpc.o src/mrpc.c
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/odb.o src/odb.c
src/odb.c: In function 'db_flush_database':
src/odb.c:1285:24: warning: variable 'pclient' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'db_reorder_key':
src/odb.c:4137:19: warning: variable 'pprev_key' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'db_paste':
src/odb.c:6026:9: warning: variable 'multi_line' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'db_save_xml':
src/odb.c:6873:11: warning: variable 'status' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'merge_records':
src/odb.c:8432:10: warning: variable 'p' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'check_open_keys':
src/odb.c:8499:10: warning: variable 'p' set but not used [-Wunused-but-set-variable]
src/odb.c:8498:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'db_check_record':
src/odb.c:8753:9: warning: variable 'multi_line' set but not used [-Wunused-but-set-variable]
src/odb.c: In function 'db_update_record':
src/odb.c:9258:32: warning: variable 'status' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ftplib.o src/ftplib.c
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mxml.o ../mxml/mxml.c
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/dm_eb.o src/dm_eb.c
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history_midas.o src/history_midas.cxx
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history_sql.o src/history_sql.cxx
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history_sqlite.o src/history_sqlite.cxx
src/history_sqlite.cxx: In member function 'std::string SqliteHistory::GetEventName(const char*)':
src/history_sqlite.cxx:941:19: warning: variable 'xevent_time' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history.o src/history.c
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/alarm.o src/alarm.c
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/elog.o src/elog.c
src/elog.c: In function 'el_search_message':
src/elog.c:394:36: warning: variable 'last' set but not used [-Wunused-but-set-variable]
src/elog.c: In function 'el_retrieve':
src/elog.c:676:22: warning: variable 'offset' set but not used [-Wunused-but-set-variable]
src/elog.c: In function 'el_delete_message':
src/elog.c:881:8: warning: variable 'n' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/strlcpy.o ../mxml/strlcpy.c
rm -f linux/lib/libmidas.a
ar -crv linux/lib/libmidas.a linux/lib/midas.o linux/lib/system.o linux/lib/mrpc.o linux/lib/odb.o linux/lib/ftplib.o linux/lib/mxml.o linux/lib/dm_eb.o linux/lib/history_midas.o linux/lib/history_sql.o linux/lib/history_sqlite.o linux/lib/history.o linux/lib/alarm.o linux/lib/elog.o linux/lib/strlcpy.o
a - linux/lib/midas.o
a - linux/lib/system.o
a - linux/lib/mrpc.o
a - linux/lib/odb.o
a - linux/lib/ftplib.o
a - linux/lib/mxml.o
a - linux/lib/dm_eb.o
a - linux/lib/history_midas.o
a - linux/lib/history_sql.o
a - linux/lib/history_sqlite.o
a - linux/lib/history.o
a - linux/lib/alarm.o
a - linux/lib/elog.o
a - linux/lib/strlcpy.o
rm -f linux/lib/libmidas-shared.so
g++ -shared -o linux/lib/libmidas-shared.so linux/lib/midas.o linux/lib/system.o linux/lib/mrpc.o linux/lib/odb.o linux/lib/ftplib.o linux/lib/mxml.o linux/lib/dm_eb.o linux/lib/history_midas.o linux/lib/history_sql.o linux/lib/history_sqlite.o linux/lib/history.o linux/lib/alarm.o linux/lib/elog.o linux/lib/strlcpy.o -lutil -lpthread -lrt -lz -lc
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mana.o src/mana.c
src/mana.c: In function 'receive_event':
src/mana.c:3251:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/mana.c: In function 'analyze_run':
src/mana.c:4052:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
g++ -DUSE_ROOT -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -pthread -m64 -I/home/exodaq/root_5.35.10/include -o linux/lib/rmana.o src/mana.c
src/mana.c: In function 'void receive_event(HNDLE, HNDLE, EVENT_HEADER*, void*)':
src/mana.c:3251:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/mana.c: In function 'INT analyze_run(INT, char*, char*)':
src/mana.c:4052:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/cnaf_callback.o src/cnaf_callback.c
src/cnaf_callback.c: In function 'cnaf_callback':
src/cnaf_callback.c:26:15: warning: variable 'b' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mfe.o src/mfe.c
src/mfe.c: In function 'manual_trigger':
src/mfe.c:276:8: warning: variable 'i' set but not used [-Wunused-but-set-variable]
src/mfe.c: In function 'initialize_equipment':
src/mfe.c:766:21: warning: variable 'eq_stats' set but not used [-Wunused-but-set-variable]
g++ -Dextname -DMANA_LITE -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/fal.o src/fal.c
src/fal.c:131:0: warning: "EQUIPMENT_COMMON_STR" redefined [enabled by default]
In file included from src/fal.c:12:0:
include/midas.h:997:0: note: this is the location of the previous definition
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c:383:1: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
src/fal.c: In function 'int sql_insert(MYSQL*, char*, char*, HNDLE, BOOL)':
src/fal.c:642:8: warning: variable 'status' set but not used [-Wunused-but-set-variable]
src/fal.c: In function 'INT ascii_write(LOG_CHN*, EVENT_HEADER*, INT)':
src/fal.c:1668:21: warning: variable 'lrs1882' set but not used [-Wunused-but-set-variable]
src/fal.c:1669:21: warning: variable 'lrs1877' set but not used [-Wunused-but-set-variable]
src/fal.c:1670:23: warning: variable 'lrs1877_header' set but not used [-Wunused-but-set-variable]
src/fal.c: In function 'INT scheduler()':
src/fal.c:5263:23: warning: variable 'actual_millitime' set but not used [-Wunused-but-set-variable]
gcc -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mserver src/mserver.c linux/lib/libmidas.a -lutil -lpthread -lrt -lz
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mhttpd.o src/mhttpd.cxx
src/mhttpd.cxx: In function 'void urlDecode(char*)':
src/mhttpd.cxx:542:14: warning: variable 'str' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'int evaluate_src(char*, char*, double*)':
src/mhttpd.cxx:5531:20: warning: variable 'status' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'void do_jrpc_rev0()':
src/mhttpd.cxx:6049:8: warning: variable 'status' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'void show_mscb_page(char*, int)':
src/mhttpd.cxx:8049:59: warning: variable 'cur_subm_index' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'void generate_hist_graph(const char*, char*, int*, int, int, time_t, int, int, int, const char*, const char*, const char*)':
src/mhttpd.cxx:11001:15: warning: variable 'black' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11001:28: warning: variable 'ltgrey' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11001:41: warning: variable 'green' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11001:48: warning: variable 'blue' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11024:11: warning: variable 'tstart' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11024:19: warning: variable 'tend' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11028:17: warning: variable 'ybuffer' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:11029:18: warning: variable 'tbuffer' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'void show_hist_config_page(const char*, const char*, const char*)':
src/mhttpd.cxx:12540:8: warning: variable 'status' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx:12542:15: warning: variable 'hKeyVar' set but not used [-Wunused-but-set-variable]
src/mhttpd.cxx: In function 'void server_loop()':
src/mhttpd.cxx:15888:8: warning: variable 'last_time' set but not used [-Wunused-but-set-variable]
gcc -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mgd.o src/mgd.c
src/mgd.c: In function 'gdImageCreateFromGif':
src/mgd.c:1894:8: warning: variable 'AspectRatio' set but not used [-Wunused-but-set-variable]
src/mgd.c:1893:8: warning: variable 'Background' set but not used [-Wunused-but-set-variable]
src/mgd.c:1892:8: warning: variable 'ColorResolution' set but not used [-Wunused-but-set-variable]
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mscb.o ./mscb/mscb.c
./mscb/mscb.c: In function 'int mscb_info(int, short unsigned int, MSCB_INFO*)':
./mscb/mscb.c:1682:8: warning: 'size' may be used uninitialized in this function [-Wuninitialized]
g++ -c -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/sequencer.o src/sequencer.cxx
src/sequencer.cxx: In function 'void init_sequencer()':
src/sequencer.cxx:722:16: warning: variable 'size' set but not used [-Wunused-but-set-variable]
src/sequencer.cxx: In function 'void show_seq_page()':
src/sequencer.cxx:916:66: warning: variable 'filename' set but not used [-Wunused-but-set-variable]
g++ -g -O2 -Wall -Wno-strict-aliasing -Wuninitialized -Iinclude -Idrivers -I../mxml -I./mscb -Llinux/lib -DHAVE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -I/usr/include/mysql -DHAVE_ODBC -DHAVE_SQLITE -DHAVE_ROOT -pthread -m64 -I/home/exodaq/root_5.35.10/include -DHAVE_ZLIB -DHAVE_MSCB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhttpd linux/lib/mhttpd.o linux/lib/mgd.o linux/lib/mscb.o linux/lib/sequencer.o linux/lib/libmidas.a linux/lib/libmidas.a -lodbc -lsqlite3 -lutil -lpthread -lrt -lz -lm
/usr/lib64/gcc/x86_64-slackware-linux/4.7.1/../../../../x86_64-slackware-linux/bin/ld: cannot find -lodbc
collect2: error: ld returned 1 exit status
make: *** [linux/bin/mhttpd] Error 1
|
|
934
|
14 Nov 2013 |
Razvan Stefan Gornea | Forum | Installation problem | Hi, Thanks a lot for the response! Yes to search packages and list their content in Slackware it is pretty similar to your illustration. Slackware seems to use iODBC in which case it would link with -liodbc I guess.
root@lheppc83:~# slackpkg file-search sql.h
Looking for sql.h in package list. Please wait... DONE
The list below shows the packages that contains "sql\.h" file.
[ installed ] - libiodbc-3.52.7-x86_64-2
You can search specific packages using "slackpkg search package".
root@lheppc83:~# cat /var/log/packages/libiodbc-3.52.7-x86_64-2
PACKAGE NAME: libiodbc-3.52.7-x86_64-2
COMPRESSED PACKAGE SIZE: 255.0K
UNCOMPRESSED PACKAGE SIZE: 1.0M
PACKAGE LOCATION: /var/log/mount/slackware64/l/libiodbc-3.52.7-x86_64-2.txz
PACKAGE DESCRIPTION:
libiodbc: libiodbc (Independent Open DataBase Connectivity)
libiodbc:
libiodbc: iODBC is the acronym for Independent Open DataBase Connectivity,
libiodbc: an Open Source platform independent implementation of both the ODBC
libiodbc: and X/Open specifications. It allows for developing solutions
libiodbc: that are language, platform and database independent.
libiodbc:
libiodbc:
libiodbc:
libiodbc: Homepage: http://iodbc.org/
libiodbc:
FILE LIST:
./
usr/
usr/share/
usr/share/libiodbc/
usr/share/libiodbc/samples/
usr/share/libiodbc/samples/iodbctest.c
usr/share/libiodbc/samples/Makefile
usr/man/
usr/man/man1/
usr/man/man1/iodbc-config.1.gz
usr/man/man1/iodbctestw.1.gz
usr/man/man1/iodbctest.1.gz
usr/man/man1/iodbcadm-gtk.1.gz
usr/bin/
usr/bin/iodbctest
usr/bin/iodbcadm-gtk
usr/bin/iodbctestw
usr/bin/iodbc-config
usr/include/
usr/include/iodbcinst.h
usr/include/sqlext.h
usr/include/iodbcunix.h
usr/include/isqltypes.h
usr/include/sql.h
usr/include/iodbcext.h
usr/include/isql.h
usr/include/odbcinst.h
usr/include/isqlext.h
usr/include/sqlucode.h
usr/include/sqltypes.h
usr/lib64/
usr/lib64/libiodbc.la
usr/lib64/libdrvproxy.so.2.1.19
usr/lib64/libiodbcinst.la
usr/lib64/libiodbcadm.so.2.1.19
usr/lib64/libiodbcinst.so.2.1.19
usr/lib64/libiodbcadm.la
usr/lib64/pkgconfig/
usr/lib64/pkgconfig/libiodbc.pc
usr/lib64/libiodbc.so.2.1.19
usr/lib64/libdrvproxy.la
usr/doc/
usr/doc/libiodbc-3.52.7/
usr/doc/libiodbc-3.52.7/ChangeLog
usr/doc/libiodbc-3.52.7/README
usr/doc/libiodbc-3.52.7/COPYING
usr/doc/libiodbc-3.52.7/AUTHORS
usr/doc/libiodbc-3.52.7/INSTALL
install/
install/doinst.sh
install/slack-desc |
|
995
|
19 May 2014 |
Razvan Stefan Gornea | Forum | Weird problem on new installation | Hello,
I have a very weird problem on a new installation of Midas running also new code. My old code was written with the CAEN VME library and run from an older PC with a CAEN interface. I now moved to a GEFanuc V7769 with a Tundra II bridge and the frontend is using the UniverseII VME library. I'm mentioning this just to point out that the code is new, not just the Midas installation. I don't think the change of VME library has anything to do with my problem.
Anyway, except the VME access, the frontend code is the same. Especially, all accesses to the online data base are identical. The main problem I'm facing is that I can not create the record with the frontend configuration data in the ODB. Here is a bit of code from my frontend_init()
rstat = db_create_record(hDB, 0, OWNER_EQUIPMENT, v1740_conf_str);
if (rstat != DB_SUCCESS) {
cm_msg(MERROR, frontend_name, "could not create record for the V1740 DAQ configuration");
cm_msg(MERROR, frontend_name, "call to db_create_record returned %d", rstat);
return rstat;
}
and these are some messages from the Midas log
Mon May 19 18:23:42 2014 [Charge Frontend,INFO] Program Charge Frontend on host lheppc78 started
Mon May 19 18:23:42 2014 [Charge Frontend,ERROR] [frontend.c:153:Charge Frontend,ERROR] could not create record for the V1740 DAQ configuration
Mon May 19 18:23:42 2014 [Charge Frontend,ERROR] [frontend.c:154:Charge Frontend,ERROR] call to db_create_record returned 320
Mon May 19 18:23:42 2014 [Charge Frontend,INFO] Program Charge Frontend on host lheppc78 stopped
The error 320 is essentially saying that there is a client which has already opened this key! But I'm pretty sure there is not!
I have checked the path OWNER_EQUIPMENT. I also used odbedit to make folders and variables in /Equipment/. I erased the hidden files in my data folder. I checked for experiment definition. I even follow an example in the docs how to clean up corrupted shared memory, erased /dev/shm.*, etc. I essentially checked item by item my old installation with the new one and everything seems the same.
So at this point I'm very puzzled!!! I don't know what to look for further. Do you have any idea what I could check for!?!
There were a few things that when wrong while getting ready the new installation but I solved them. So just to mention in case it is important.
A) I had difficulties to start the system on the new machine. Some hidden files in the data folder: .ODB.SHM .SYSTEM.SHM etc. where somehow created with root:root ownership and then mlogger et co. could not start! Also, some files in /dev/shm/ where created the same and it gave some problems. I solved these simply by chown all to user:group But I don't understand why this happened and I don't remember having to do that on my old system.
B) I use Slackware and I had this problem that instead of having the ODBC library I had only the iODBC and so I made the switch to that to be able to compile (which by the way seemed fine). I have no idea if this could somehow be related to my current problem.
Thanks a lot for your help!
Cheers,
Razvan Gornea
|
|
996
|
22 May 2014 |
Razvan Stefan Gornea | Forum | Weird problem on new installation | I reduced the parameter space a little bit and I think the problem is somewhere in the framework. What I did is first to make a short program which accesses the ODB and I was able to access the Settings record. Everything seems to work fine, if parts or all of the record is missing then it is created automatically, etc.
Then I reduced my frontend to essentially a few lines in the frontend_init() which are identical to what I did in the small test program. Still when running the frontend it doesn't work and db_create_record() returns the error DB_OPEN_RECORD. I have tried something crazy, i.e. to disconnect the experiment and then reconnect in the frontend_init() and I was able to write the Settings record in the ODB! I have checked in mfe.c and odb.c and I think when my frontend_init() gets called, the record is already open!
Does anybody skilled with Midas know what I can do to solve or investigate this problem further?
This is the small program that can successfully access the ODB and create the Settings record.
// test program
#include <stdio.h>
#include <stdlib.h>
#include "midas.h"
#include "v1740_daq_settings.h"
V1740_DAQ_CONF_STR(v1740_conf_str);
int main(void)
{
int status;
HNDLE hDB;
char temp_name[NAME_LENGTH];
status = cm_connect_experiment("", "", "test", NULL);
if (status != CM_SUCCESS) {
printf("Oups could not connect to the experiment\n");
return 1;
}
cm_get_experiment_database(&hDB, NULL);
status = db_create_record(hDB, 0, OWNER_EQUIPMENT, v1740_conf_str);
if (status != DB_SUCCESS) {
printf("Oups failed to create DB record!\nCall to db_create_record() has returned %d", status);
cm_disconnect_experiment();
return 2;
}
cm_get_experiment_name(temp_name, NAME_LENGTH-1);
cm_msg(MINFO, "test", "experiment name is <|%s|>", temp_name);
printf("The test is successful!\nNo errors occurred!\n");
cm_disconnect_experiment();
return 0;
}
This is the frontend_init() part (there is nothing left in the frontend anyway). This is exactly the same code like the previous one, but it won't work! So I concluded that the problem is already present when frontend_init() gets call in mfe.c
#include <stdio.h>
#include <stdlib.h>
#include "midas.h"
#include "v1740_daq_settings.h"
/* make frontend functions callable from the C framework */
#ifdef __cplusplus
extern "C" {
#endif
/*-- Globals -------------------------------------------------------*/
/* The frontend name (client name) as seen by other MIDAS clients */
char *frontend_name = "Charge Frontend";
/* The frontend file name, don't change it */
char *frontend_file_name = __FILE__;
/* frontend_loop is called periodically if this variable is TRUE */
BOOL frontend_call_loop = FALSE;
/* a frontend status page is displayed with this frequency in ms */
INT display_period = 2100;
/* maximum event size produced by this frontend */
INT max_event_size = 2304 * 1024 + 128;
/* maximum event size for fragmented events (EQ_FRAGMENTED) */
INT max_event_size_frag = 5 * 1024 * 1024;
/* buffer size to hold events */
INT event_buffer_size = 64 * (2304 * 1024 + 128);
V1740_DAQ_CONF_STR(v1740_conf_str); // string representation for the database record for the configuration of the v1740 DAQ board
HNDLE hDB = 0; // handle on database
HNDLE hConf = 0; // handle for the configuration section
/*-- Function declarations -----------------------------------------*/
INT frontend_init();
// ... etc ...
/*-- Equipment list ------------------------------------------------*/
#undef USE_INT
EQUIPMENT equipment[] = {
{"CAEN_V1740", // equipment name
{1, 0, // event ID, trigger mask
"SYSTEM", // event buffer
EQ_POLLED | EQ_MANUAL_TRIG, // equipment type
LAM_SOURCE(0, 0xFFFFFF), // event source crate 0, all stations
"MIDAS", // data format
TRUE, // equipment enabled
RO_RUNNING, // read only when running and update ODB
500, // poll for 500 ms
0, // stop run after this event limit
0, // number of sub events
0, // don't log history
"", "", "",
},
read_CAEN_V1740_event, // readout routine
},
{""}
};
#ifdef __cplusplus
}
#endif
INT frontend_init()
{
INT rstat = SUCCESS; // temp variable for Midas func. return codes
char temp_name[NAME_LENGTH];
// cm_disconnect_experiment();
// cm_msg(MINFO, frontend_name, " *** DISCONNECTED FROM THE EXPERIMENT *** ");
// rstat = cm_connect_experiment("", "", frontend_name, NULL);
// if (rstat != CM_SUCCESS) {
// cm_msg(MERROR, frontend_name, "Oups could not connect to the experiment");
//
// return rstat;
// }
// cm_msg(MINFO, frontend_name, " *** CONNECTED AGAIN TO THE EXPERIMENT *** ");
// get handle on database
cm_get_experiment_database(&hDB, NULL);
// create or check for configuration data structure
rstat = db_create_record(hDB, 0, OWNER_EQUIPMENT, v1740_conf_str);
if (rstat != DB_SUCCESS) {
cm_msg(MERROR, frontend_name, "could not create record for the V1740 DAQ configuration");
cm_msg(MERROR, frontend_name, "call to db_create_record returned %d", rstat);
cm_get_experiment_name(temp_name, NAME_LENGTH-1);
cm_msg(MERROR, frontend_name, "experiment name is <|%s|>", temp_name);
return rstat;
}
cm_msg(MINFO, frontend_name, " *** SUCCESSFULLY CREATED THE RECORD IN ODB *** ");
return 11;
// return SUCCESS;
}
|
|
1001
|
27 May 2014 |
Razvan Stefan Gornea | Forum | Weird problem on new installation | I investigated further this problem and this is what I think is going on. Essentially when creating the Settings key, the framework scans all the subkeys of the parent key to see if any are open. If that's the case it then returns an error on opening the Settings key! Here are the details:
db_create_record() : check if global open_count neq. 0
-> db_scan_tree_link() : call back to check_open_keys()
-> check_open_keys() : implicitly changes global open_count neq. 0 when key->notify_count > 0
-> db_scan_tree_link() : if key.type eq. TID_KEY then get list subkeys
-> for all subkey : call recursively db_scan_tree_link()
In my case I have the following structure in ODB right before the framework calls frontend_init():
/Equipment/CAEN_V1740 [CLOSE]
/Equipment/CAEN_V1740/Variables [CLOSE]
/Equipment/CAEN_V1740/Common [OPEN]
/Equipment/CAEN_V1740/Statistics [OPEN]
/Equipmemt/CANE_V1740/Settings [CLOSE]
What I don't know for sure is if it is expected to have Common and Statistics still open when frontend_init() is called. Also, I don't understand if the recursive check for open links is really necessary!?! If yes then the small example just in from of the db_create_record() code makes no sense! As well as the example in the documentation!
I have checked with a debugger that my database is not somehow corrupted and indeed is the framework that opens Common and Statistics. To me everything looks fine in the sense that I think it is expected to have these two keys open!
This is the output from a changed odb.c to debug:
exodaq@lheppc78:~/daq/xlr$ cat ~/xlr/midas.log
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Program Charge Frontend on host lheppc78 started
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found write to notify_count for Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] found an open key with message /Equipment/CAEN_V1740/Common open 1 times by "Charge Frontend"
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] found an open key with message /Equipment/CAEN_V1740/Common open 1 times by "Charge Frontend"
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] status after creating record for the statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Has created successfully a statistics record
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found write to notify_count for Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Has open successfully a statistics record
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] successfully terminated equipment registration
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] found an open key with message /Equipment/CAEN_V1740/Common open 1 times by "Charge Frontend"
Tue May 27 11:08:05 2014 [Charge Frontend,ERROR] [odb.c:8869:check_open_keys,ERROR] Found open key named Common
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Found read access to Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] found an open key with message /Equipment/CAEN_V1740/Statistics open 1 times by "Charge Frontend"
Tue May 27 11:08:05 2014 [Charge Frontend,ERROR] [odb.c:8869:check_open_keys,ERROR] Found open key named Statistics
Tue May 27 11:08:05 2014 [Charge Frontend,ERROR] [frontend.c:151:Charge Frontend,ERROR] could not create record for the V1740 DAQ configuration
Tue May 27 11:08:05 2014 [Charge Frontend,ERROR] [frontend.c:152:Charge Frontend,ERROR] call to db_create_record returned 320
Tue May 27 11:08:05 2014 [Charge Frontend,ERROR] [frontend.c:154:Charge Frontend,ERROR] experiment name is <|xlr|>
Tue May 27 11:08:05 2014 [Charge Frontend,INFO] Program Charge Frontend on host lheppc78 stopped |
|
2407
|
17 May 2022 |
Razvan Stefan Gornea | Info | MIDAS switched to C++ | Hi, I have three naive questions about this:
- have you posted somewhere this guide about converting C frontends to C++?
- it was mentioned previously that there will be a 'tag the last "C" midas', which version is it?
- it means that even a simple example like odb_test.c cannot be compile anymore? Even when using g++?
Something like
g++ -I $HOME/daq/packages/midas/include/ -L $HOME/daq/packages/midas/lib/ odb_test.c -l midas
is expected to fail or is just me glitching? Is it because of thread library differences?
Thanks!
> The last bits of code to switch MIDAS to C++ have been committed, see tag midas-2019-05-cxx.
>
> Since the cmake conversion is still in progress, for now, I recommend using the old "make" build for trying this update.
>
> From the switch to C++, the biggest change is the requirement that frontend programs be build and linked
> using the C++ compiler. Since mfe.o and the rest of MIDAS are built with C++, building frontends
> with C is no longer possible.
>
> To help with this, I will post a short guide for converting C frontends to C++.
>
> K.O. |
|
831
|
30 Aug 2012 |
Raquel Castillo | Forum | MIDAS in Windows | Hi,
I need to install MIDAS on a Windows system (Microsoft Windows Server 2003).
The computer has the Microsoft Visual C++ 2010 Express version.
I have downloaded the MIDAS packages using the tarball mechanism. I have create
the environment variables without problems and I have create the file
%SystemRoot%\system32\exptab
But when I try to build MIDAS and I do
nmake -f makefile.nt
I have the following problem:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'src/mhttpd.c'
Stop.
I don't understand this problem. Can anybody help me, please?
Thanks in advance!!! |
|
840
|
23 Oct 2012 |
Raquel Castillo | Forum | MIDAS in Windows | Hi Pierre-André,
sorry for the long delay, another things keep me out of this computer.
Thanks a lot for correcting makefile.nt and the other applications!
Now I have try, downloading the MIDAS packages from the tarball mechanism, as
before,
and now it seems that the previous problems are solved. It remains only one small
problem, it is related to the odbedit.
I attach here the figure with the error that is reported by the computer. Is it
possible that is another file that needs to be updated? Can you help me with that?
Thanks a lot in advance!!!!
> Hi Raquel,
>
> The makefile.nt has been corrected.
> Obviously Midas on Windows has not been updated for quite a while.
> mhttpd.c has been converted to c++ (mhttpd.cxx) as well as a couple of other
> applications.
>
> Please give a try, PAA
>
> > Hi,
> >
> > I need to install MIDAS on a Windows system (Microsoft Windows Server 2003).
> > The computer has the Microsoft Visual C++ 2010 Express version.
> > I have downloaded the MIDAS packages using the tarball mechanism. I have create
> > the environment variables without problems and I have create the file
> > %SystemRoot%\system32\exptab
> > But when I try to build MIDAS and I do
> > nmake -f makefile.nt
> > I have the following problem:
> > Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > NMAKE : fatal error U1073: don't know how to make 'src/mhttpd.c'
> > Stop.
> >
> > I don't understand this problem. Can anybody help me, please?
> >
> > Thanks in advance!!! |
| Attachment 1: MIDAS_odbedit.bmp
|
|
377
|
22 May 2007 |
Randolf Pohl | Bug Report | analyzer_init called by odb_load | Hi,
I wonder why mana.c:odb_load() calls analyzer_init(). This way analyzer_init
is called TWICE or more times:
first from mana.c:mana_init(), for each invocation of the analyzer, and
second from mana.c:odb_load(), for each run to be analyzed
Isn't this a bug? It can mess up several things (like mallocs) if you don't
take the necessary precautions. Other module_init functions are correctly
called only once, before all runs are analyzed.
I have the feeling, that odb_load should NOT call analyzer_init. Or am I wrong
(probably, but please explain to me)? Do I have to live with it and make sure
that my beautiful global initialization in analyzer_init is only done once?
:-)
Cheers,
Randolf
And here is the annotated log using the ROOT example experiment
(several modules changed/added to print their respective names)
:~/midas/examples/root> ./analyzer -e exa_root -i run%05d.mid -r 1 3
analyzer_init <-- ok
Root server listening on port 9090...
adc_calib_init <-- ok
adc_summing_init <-- ok
scaler_init <-- ok
Running analyzer offline. Stop with "!"
Set run number 1 in ODB
Load ODB from run 1...
analyzer_init <-- not ok, or is it?
OK
run00001.mid:777 events, 0.00s
Set run number 2 in ODB
Load ODB from run 2...
analyzer_init <-- not ok, or is it?
OK
run00002.mid:7227 events, 0.03s
Set run number 3 in ODB
Load ODB from run 3...
analyzer_init <-- not ok, or is it?
OK
run00003.mid:13866 events, 0.06s
adc_calib_exit
adc_summing_exit
scaler_exit
analyzer_exit |
|
379
|
22 May 2007 |
Randolf Pohl | Bug Report | analyzer_init called by odb_load | Thanks for the quick reply, Stefan.
Please don't change anything in the code unless you find it really important. I guess
changing the analyzer_init prototype will break a lot of code out there?
In fact, I think I do understand this behavior now.
And even without your suggested fix there is a simple workaround: I add a static
variable to my analyzer_init.cxx file, and do something similar to your bFirst fix.
In conclusion, commit your fix if it does not harm others. Postpone this commit to a
future new version of midas which breaks a lot of things anyway...
A last question, for me to understand: Why not call db_open_record in
ana_begin_of_run then?
Cheers,
Randolf |
|