Back Midas Rome Roody Rootana
  Midas DAQ System, Page 1 of 136  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Topic Subjectup
  Draft   05 Mar 2018  Suggestion 
  Draft   27 Jun 2019 Hassan  
  Draft   20 Feb 2020 Marius Koeppel  
We also agree and found the problem now. Since we build everything (MIDAS Event Header, Bank Header, Banks etc.) in the FPGA we had some struggle with the MIDAS data format (http://lmu.web.psi.ch/docu/manuals/bulk_manuals/software/midas195/html/AppendixA.html). We thought that only the MIDAS Event needs to be aligned to 64 bit but as it turned out also the bank data (Stefan updated the wiki page already) needs to be aligned. Since we are using the BANK32 it was a bit unclear for us since the bank header is not 64 bit aligned. But we managed this now by adding empty data and the system is running now.

Our setup looks like this:

- mfe.cxx multithread equipment
- mfe readout thread grabs pointer from dma ring buffer 
- since the dma buffer is volatile we do copy_n for transforming the data to MIDAS 
- the data is already in the MIDAS format so done from our side :)
- mfe readout thread increments the ring buffer
- mfe main thread grabs events from ring buffer, sends them to the mserver

From the firmware side we have an Arria 10 development board and 

But now I am curious, which DMA controller you use? The Altera or Xilinx PCIe block with the vendor supplied DMA driver? Or you do DMA on an ARM SoC FPGA? (no PCI/PCIe, 
different DMA controller, different DMA driver).

I am curious because we will be implementing pretty much what you do on ARM SoC FPGAs pretty soon, so good to know
if there is trouble to expect.

But I will probably use the tmfe.h c++ frontend and a "pure c++" ring buffer instead of mfe.cxx and the midas "rb" ring buffer.

(I did not look at your code at all, there could be a bug right there, this ring buffer stuff is tricky. With luck there is no bug
in your dma driver. The dma drivers for our vme bridges did do have bugs).

K.O.
  2433   19 Aug 2022 Konstantin OlchanskiBug Fix"Detected duplicate or non-monotonous data" in history files
serious (but rare) bug was fixed in the history reader. unlucky experiment would see 
errors about "Detected duplicate or non-monotonous data" in some history file, fixed by 
removing/renaming the offending file. (reported by MEG experiment)

it turns out there was nothing wrong with the data files (good), but there
was a nasty bug in the history reader. it did not ensure that we read history
files in chronological order. under some conditions order of files could be
reversed, older files would be read after newer files and trip the built-in
protection against returning non-monotonically increasing history data to the user.

fixed commit 
https://bitbucket.org/tmidas/midas/commits/9893f85ebe33e96cc63f501a0f89e1f8932c894d

for more details, see https://bitbucket.org/tmidas/midas/issues/350/file-history-non-
monotonic-time

K.O.
  2436   23 Aug 2022 Konstantin OlchanskiBug Fix"Detected duplicate or non-monotonous data" in history files
> serious (but rare) bug was fixed in the history reader.

previous fix was incomplete. please update to git commit
https://bitbucket.org/tmidas/midas/commits/b343c3c98e4e6fd00a00cf686c74c7ccc6da0c63

K.O.
  2450   17 Nov 2022 Konstantin OlchanskiBug Fix"Detected duplicate or non-monotonous data" in history files
> > serious (but rare) bug was fixed in the history reader.
> previous fix was incomplete. please update to git commit
> https://bitbucket.org/tmidas/midas/commits/b343c3c98e4e6fd00a00cf686c74c7ccc6da0c63

a race condition between reading history file in mhttpd and writing history file in 
mlogger was accidentally introduced. mhttpd would file spurious errors about "timestamp 
is after last timestamp".

fixed, please update to git commit
https://bitbucket.org/tmidas/midas/commits/7a9f6e0c58ffddcacb9ee19934ce3e2033a805ef

fix race condition in history file reader - a race condition was added accidentally - 
first the reader remembers the history file size and the time of the last entry, then it 
goes to read the file and bombs if at the same time mlogger added more entries - their 
time is after the remembered time of last entry and error "timestamp is after last 
timestamp" is triggered.

K.O.
  999   26 May 2014 Dan MelconianSuggestion"Edit-on-end" would be nice
We use the "Edit-on-start" and it's great.  But sometimes, something breaks
during the run, or you didn't realize you forgot to plug in a cable, or
whatever.  It'd be nice to have an "Edit-on-end" where you could prompt the user
to answer simple questions (like "Was this a good run?  [y/n]" or "Was the data
polarized?  [y/n]") and/or add a quick summary of what happened that run.


Thanks in advance,

Dan
  1000   26 May 2014 Stefan RittSuggestion"Edit-on-end" would be nice
We have similar demands, and we solve it in the following:

We use a run database. In the simplest case, this can be a text file which gets written at the end of the file. The 
mlogger has a built in SQL interface, so one can keep that table even inside a SQL interface. The per-run-
information then contains the run number, start/stop time, number of events, some run parameters and a "junk" 
flag. So if a run has a problem, one can set the junk flag by accessing the database (or text file) and setting this 
flag. In many cases you see that a run had a problem not at the end of the run, but a bit later. You mayby realize 
that the last two or three runs had the problem. With the run database approach, you can flag any run as "junk" 
later, which we need often, An edit-on-end would not make this possible.

So technically putting and edit-on-end is not a problem, but your life might be much easier if you use a run 
database as outlined above.

Best regards,
Stefan
  466   10 Mar 2008 Exaos LeeSuggestion"Makefile-by-EL" updated
> Not that the current Makefile is too pretty (I have seen worse), but it 
works and it is fairly compact for a project of 
> this complexity, it handles a large number of operating systems and build 
options very efficiently.
> 
> I think you found that out with your rewriting exercise - your version of 
the Makefile contains all the same code, 
> just rearranged to suite your taste, with existing bugs preserved and new 
bugs added.

I derived the new Makefile from the original one so that feathers and bugs are 
also included. 
I havn't experiences on platforms other than Linux and MacOS, so I cannot 
recognize bugs on 
other platforms if they exists in the original one. And if there are bugs, 
hope users can figure
them out.

>
> As they say, the devil is in the details. I notice some subtle changes in 
your Makefile that make me go "what?":
> 
> 1) the command for building the midas shared library used to be "ld -
shared", in your version, "-shared" is gone. 
> But check with the GCC manual, today's recommended command is probably "gcc -
shared".

Fixed.

> 2) mhdump is now linked with ROOT, but I wrote it recently enough to 
remember that it does not use ROOT

The building dependence on ROOT of mhdump may be eliminated by changing the 
specific target.

> 3) hand-crafted dependancies have been replaced with generic "almost 
every .o depends on every .h", which is 
> incorrect. The "almost every .o" part bothers me.

Fixed now.

> 4) "make clean" runs "rm -rf" - plain scary.

Fixed.

> 5) "$(shell ...)" is overused

Replaced with GNU make internal methods.


> I think by the end all these little details are sorted out and all the 
quirks are put back in, your Makefile will look no 
> better than the current Makefile.

I realized it now. But anyway, it looks tidy to me now. I still hope to use 
AUTOTOOLS with MIDAS.
 
> > 2. The file is less than 400 lines now. The original one is more than 500 
lines.

The new one is about 430 lines. Hmmm, it reaches the original one which is 
more than 600 lines.

> 
> It looks like your savings came from removing comments, removing hand-
crafted dependancy lists and replacing 
> fairly verbose "make install" targets (which we do not use anyway) with your 
own much simpler scripts.
> 
> All the juicy bits needed to actually build all the code appear to take 
about as much space as before.
> 
> Also the original mistake of recompiling programs when they only need 
relinking was not fixed. (For example, 
> when libmidas is updated, to update mhttpd, the current Makefile needlessly 
recompiles mhttpd.c. Better use 
> would be to compile mhttpd.c into mhttpd.o, then only a relink is needed).

Fixed.

> 
> Most experience with autoconf/automake is all negative. The promise 
was "never debug your Makefile ever 
> again!", delivered was "debug the configure script instead!". In practice, 
with autoconf/automake, you try to run 
> configure, kludge it until it stops crashing, then tweak the 
incomprehensible Makefiles it produces until the code 
> compiles.
> 
> K.O.

====================================================
Maybe BUGS or FEATURES in this new one:
1. The shared libmidas.so and the static libmidas.a are built sperately. 
The "libmidas.a" is 
always built whether "NEED_SHLIB" is set or not. And all executables are built 
staticly default. 
I commented this in the Makefile-by-EL. Hence, if you want to use libmidas.so 
with PyMIDAS and
do not want to encounter "Segmentation fault" while executing the utilies 
linked dynamicly, you
may try this one.
2. I found that "minife" is failed to be built, so I remove it from the 
example list.
3. Some bugs while building on MacOS Tiger 10.4.11 PPC are commented out in 
the Makefile. These
bugs are still exists in the original one.
4. Using "VPATH" instead of adding pathnames.
5. Using "UTILS_SUID" to handle utilities which need SUID mode. And 
the "UTILS_SUID_NEED" may be
defined in the OS-specific field, so you need not to use OS-specific commands 
in the "install"
target.
6. Using "tr" with "uname" in order to delete some extra "ifeq 
($(OSTYPE),...)".
7. Other things, please see the file.

Anyway, easier building is my purpose. :-)
Attachment 1: Makefile-by-EL
#-include MIDAS-env.mk --- split the environment setup in a seperate file?

# initialized flags

#CC = icc
#FC = ifort
#LD = ld
CFLAGS   = -g -O3 -Wall -Wuninitialized -DINCLUDE_FTPLIB

###########################################################################
## Environments setup for building MIDAS/PSI

## Prefix
ifndef PREFIX
PREFIX = /usr/local
endif

# User defined flags for compiler
USERFLAGS     =

# Do you need to compile the shared library? If so, set "1" here.
NEED_SHLIB    =

# If RPATH needed ...
NEED_RPATH    =

# If static ROOT libaries needed ...
NEED_LIBROOTA =

# If strlcpy.o needed ...
NEED_STRLCPY  = 1

# If zlib needed ...
NEED_ZLIB     = 1

# MIDAS max event size
MIDAS_MAX_EVENT_SIZE =

# OS specific programs included
SPECIFIC_OS_PRG      =

# ..? Why it is needed?
MIDAS_PREF_FLAGS     =

# Build examples or not? If so, set "1" here ...
EXAMPLES_NEED = 1

## installer
INSTALL  = $(shell which install)

# **** CAUTION ****
# **** On MacOS Tiger, "/usr/bin/install" doesn't accept "-D" option!
# **** NEED to be fixed ...
ifndef INSTALL
INSTALL  = ./install.sh
else
INS_OPTS = -v -D
endif

# MXML dir
ifndef MXML_DIR
MXML_DIR = ../mxml
endif

# MySQL
# **** CAUTION ****
# **** On MacOS Tiger (10.4.11), the "MYSQL_CONFIG" will be always defined because
# **** "which" will always return something whether it finds the exec or not!
# **** NEED to be fixed!
MYSQL_CONFIG := $(shell which mysql_config 2> /dev/null)

ifdef MYSQL_CONFIG
MYSQLINCDIR := $(shell mysql_config --cflags | sed -e 's,^.*-I\([^ ]*\).*$$,\1,' -e s/\'//g)
NEED_MYSQL  := $(shell if test -e $(MYSQLINCDIR)/mysql.h ; then echo 1; fi)
endif

###########################################################################
## Check OS Type for OS-specified flags

# *** CAUTION *** Does "tr" exist on all POSIX platform?
OSTYPE = $(shell uname | tr '[A-Z]' '[a-z]')

ifeq ($(OSTYPE), linux)
# > 2GB file support
CFLAGS  += -D_LARGEFILE64_SOURCE
CFLAGS  += -DOS_LINUX -fPIC -Wno-unused-function
LDFLAGS += -lutil -lpthread
NEED_ZLIB        = 1
SPECIFIC_OS_PRG += mlxspeaker dio
endif

ifeq ($(OSTYPE), osf1)
CFLAGS  += -DOS_OSF1
FFLAGS  += -nofor_main -D 40000000 -T 20000000
LDFLAGS += -lc -lbsd
endif

ifeq ($(OSTYPE), ultrix)
CFLAGS  += -DOS_ULTRIX -DNO_PTY
endif

ifeq ($(OSTYPE), freebsd)
CFLAGS  += -DOS_FREEBSD
LDFLAGS += -lbsd -lcompat
endif

ifeq ($(OSTYPE), darwin)
CFLAGS  += -DOS_LINUX -DOS_DARWIN -DHAVE_STRLCPY -fPIC -Wno-unused-function
LDFLAGS += -lpthread
NEED_RANLIB      = 1
SPECIFIC_OS_PRG += mlxspeaker
endif

ifeq ($(OSTYPE), cygwin_nt-5.1)
OSTYPE = cygwin
endif

ifeq ($(OSTYPE), cygwin)
CFLAGS  += -DOS_LINUX -DOS_CYGWIN -Wno-unused-function
LDFLAGS += -lutil -lpthread
endif

ifeq ($(OSTYPE), solaris)
CFLAGS  += -DOS_SOLARIS
LDFLAGS += -lsocket -lnsl
endif

###########################################################################
## Processing environment for building flags

CFLAGS += $(MIDAS_PREF_FLAGS) $(USERFLAGS)

ifdef MIDAS_MAX_EVENT_SIZE
CFLAGS   += -DMAX_EVENT_SIZE=$(MIDAS_MAX_EVENT_SIZE)
endif # MIDAS_MAX_EVENT_SIZE

ifdef NEED_MYSQL
CFLAGS     += -DHAVE_MYSQL $(shell $(MYSQL_CONFIG) --include)
LDFLAGS    += $(shell $(MYSQL_CONFIG) --libs)
NEED_ZLIB   = 1
endif # NEED_MYSQL

ifdef ROOTSYS
ROOTLIBS   := $(shell $(ROOTSYS)/bin/root-config --libs)
ROOTCFLAGS := $(shell $(ROOTSYS)/bin/root-config --cflags)

ifdef NEED_RPATH
ROOTLIBS   += -Wl,-rpath,$(ROOTSYS)/lib
endif

ifdef NEED_LIBROOTA
ROOTLIBS   := $(ROOTSYS)/lib/libRoot.a -lssl -ldl -lcrypt
endif

CFLAGS     += $(ROOTCFLAGS)
endif # ROOTSYS

ifdef NEED_ZLIB
CFLAGS     += -DHAVE_ZLIB
LDFLAGS    += -lz
endif # ZLIB

###########################################################################
## Processing building targets

## Directories needed
INC_DIR = include
SRC_DIR = src
UTL_DIR = utils
DRV_DIR = drivers
EXM_DIR = examples

## Driectories which will be created
OS_DIR  = $(OSTYPE)
LIB_DIR = $(OS_DIR)/lib
BIN_DIR = $(OS_DIR)/bin
DIRS    = $(OS_DIR) $(LIB_DIR) $(BIN_DIR)

CFLAGS += -I$(INC_DIR) -I$(DRV_DIR) -I$(MXML_DIR)

## Directories for install
INSTDIR_BIN = $(PREFIX)/bin
INSTDIR_INC = $(PREFIX)/include
INSTDIR_LIB = $(PREFIX)/lib
INSTDIR_DRV = $(PREFIX)/driver

## Utilities
UTILS = mserver mhttpd mlogger odbedit mtape  mhist    \
	mstat   mcnaf  mdump   mhdump  mchart odbhist  \
	melog   webpaw lazylogger   stripchart.tcl  \
	$(SPECIFIC_OS_PRG)

# Utilities need to change SUID mode
UTILS_SUID_NEED = dio mhttpd webpaw
UTILS_SUID = $(UTILS_SUID_NEED:%=$(BIN_DIR)/%)

## Analyzer objects
ANALYZER  = $(LIB_DIR)/mana.o

ifdef CERNLIB
ANALYZER += $(LIB_DIR)/hmana.o
endif
ifdef ROOTSYS
ANALYZER += $(LIB_DIR)/rmana.o
endif

## Objects for building $(LIBMIDAS_A) and $(LIBMIDAS_SO)
OBJS4LIB_ALL = midas.o system.o mrpc.o odb.o ybos.o ftplib.o history.o alarm.o elog.o
OBJS4LIB_A   = $(OBJS4LIB_ALL:%=$(LIB_DIR)/%) $(LIB_DIR)/cnaf_callback.o
OBJS4LIB_SO  = $(OBJS4LIB_ALL:%=$(LIB_DIR)/%)

## MXML OBJS
MXML_OBJS_NEED  = mxml.o
ifdef NEED_STRLCPY
MXML_OBJS_NEED += strlcpy.o
endif

MXML_OBJS = $(MXML_OBJS_NEED:%=$(LIB_DIR)/%)

## Objects for install
OBJS_INS_NEED = mfe.o fal.o
OBJS_INS = $(OBJS_INS_NEED:%=$(LIB_DIR)/%)

## library
LIBMIDAS_A  = $(LIB_DIR)/libmidas.a

ifdef NEED_SHLIB
LIBMIDAS_SO = $(LIB_DIR)/libmidas.so

CFLAGS     += -shared -fPIC
LDFLAGS    += -shared
# if need to link utilities dynamically with libmidas.so, add this flag...
LDFLAGS_SH += -shared -L$(LIB_DIR) -lmidas
endif # NEED_SHLIB

## Examples
EXAMPLES = consume produce rpc_test msgdump minirc odb_test #minife - failed building!

## All executables
EXECS  = $(UTILS:%=$(BIN_DIR)/%)
ifdef EXAMPLES_NEED
EXECS += $(EXAMPLES:%/$(BIN_DIR)/%)
endif

###########################################################################

CXXFLAGS  = $(CFLAGS)

ifdef ROOTSYS
CXXFLAGS += -DHAVE_ROOT
endif

all: check-mxml $(DIRS) $(LIBMIDAS_A) $(LIBMIDAS_SO) \
     $(ANALYZER) $(OBJS_INS) $(EXECS)

.PHONY: clean

examples: $(LIBMIDAS_A) $(EXAMPLES:%=$(BIN_DIR)/%)

## Static
static:
	@rm -f $(EXECS)
	@$(MAKE) USERFLAGS=-static

## Install
install: install-utils install-includes install-libs \
	 install-drivers install-src install-examples
	@echo "..."
	@echo "... Happy working with MIDAS! "
	@echo "..."

###########################################################################

$(DIRS):
	@echo "Making directory $@ ..."
	@mkdir -p $@

## Libraries
$(LIBMIDAS_A): $(OBJS4LIB_A) $(MXML_OBJS)
	@rm -f $@
	@echo "Creating $@ ..."
	@ar -crv $@ $^
ifdef NEED_RANLIB
	@ranlib $@
endif

$(LIBMIDAS_SO): $(OBJS4LIB_SO) $(MXML_OBJS)
	@rm -f $@
	@echo "Creating $@ ..."
	@$(CC) $(LDFLAGS) -o $@ $^

## MXML-check
check-mxml:
ifdef NEED_STRLCPY
	@if test ! -e $(MXML_DIR)/strlcpy.h ; then \
		echo "Please download mxml from: " ; \
		echo "http://midas.psi.ch/htmldoc/quickstart.html" ;\
		exit 1; \
	fi
... 135 more lines ...
  467   10 Mar 2008 Exaos LeeSuggestion"Makefile-by-EL" updated
Sorry, this line:
EXECS += $(EXAMPLES:%/$(BIN_DIR)/%)
should be replaced by
EXECS += $(EXAMPLES:%=$(BIN_DIR)/%)
  468   11 Mar 2008 Stefan RittSuggestion"Makefile-by-EL" updated
The linking of mhttpd misses a "-lm":

cc -g -O3 -Wall -Wuninitialized -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DOS_LINUX
-fPIC -Wno-unused-function   -DHAVE_ZLIB -Iinclude -Idrivers -I../mxml -o
linux/bin/mhttpd linux/lib/mhttpd.o linux/lib/mgd.o linux/lib/libmidas.a -lutil
-lpthread -lz
linux/lib/mhttpd.o(.text+0xe08f): In function `show_custom_gif':
src/mhttpd.c:5058: undefined reference to `log'
linux/lib/mhttpd.o(.text+0xe0a8):src/mhttpd.c:5058: undefined reference to `log'

The header of the makefile should contain a short description, the author(s), an
$Id:$ tag for SVN, some explanation what "icc", "ifort" means, a note about the
CFLAGS and a clear statement what can be modified by the user and why and what not.
  469   11 Mar 2008 Exaos LeeSuggestion"Makefile-by-EL" updated
> The linking of mhttpd misses a "-lm":
> 
> cc -g -O3 -Wall -Wuninitialized -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DOS_LINUX
> -fPIC -Wno-unused-function   -DHAVE_ZLIB -Iinclude -Idrivers -I../mxml -o
> linux/bin/mhttpd linux/lib/mhttpd.o linux/lib/mgd.o linux/lib/libmidas.a -lutil
> -lpthread -lz
> linux/lib/mhttpd.o(.text+0xe08f): In function `show_custom_gif':
> src/mhttpd.c:5058: undefined reference to `log'
> linux/lib/mhttpd.o(.text+0xe0a8):src/mhttpd.c:5058: undefined reference to `log'
> 

Strange. I tested it on Debian Linux 4.0r2 AMD64 with gcc 4.1.2, MIDAS SVN 4124. It worked fine.
Anyway, it can be fixed by addling "-lm" to the initial"LDFLAGS".

> The header of the makefile should contain a short description, the author(s), an
> $Id:$ tag for SVN, some explanation what "icc", "ifort" means, a note about the
> CFLAGS and a clear statement what can be modified by the user and why and what not.

OK. I will comment it in detail.
  489   16 Jun 2008 Stefan RittBug Fix"Missing event" problem fixed in front-end framework
Since the very beginning midas had the problem that the last event of a run was
sometimes missing in the data. While for most experiments this is not an issue,
it starts to hurt on experiments using event building (front-end 1 and front-end
2 in the example below). A missing event can screw up the event builder on the
next begin of run, where the "missing event" would show up as the first event of
the new run, triggering an event mismatch error in the event builder.

After some analysis, we identified the problem as follows. Assume FE1 controls
the trigger, while FE2 generates the second event fragment.

1) Stop is requested to FE1
2) tr_stop gets called on FE1
3) tr_stop calls end_of_run() use code
4) end_of_run() disables the trigger
5) FE1 finishes stop transition
6) Stop is requested to FE2
7) FE2 finishes stop transition

What can now happen is the following: An additional event occurs between 2) and
4). This event triggers ADCs and TDCs, and is then stored in the front-end
hardware. FE2 sees this event, since it has not yet done the stop transition,
and reads it out. FE1 is however already in the end_of_run() routine, and simply
disables the trigger, without reading this last event, and thus causing the
event mismatch at the beginning of the next run.

To fix the problem, the framework in mfe.c was changed:

1) Stop is requested to FE1
2) tr_stop gets called on FE1
3) tr_stop calls end_of_run() use code
4) end_of_run() disables the trigger
4b) tr_stop calls check_polled_events()
5) FE1 finishes stop transition
6) Stop is requested to FE2
7) FE2 finishes stop transition

The new routine check_polled_events checks if there is any more event in the
hardware by calling the user polling routine. If there is one more event, calls
the user readout routine and sends it to the back-end before concluding the run
transition. 

This modification solved our problem at the MEG experiment at PSI, but it might
be good that all experiments using event building update midas to revision 4225.

I do not expect any bad side effect, but one never knows. So if there are new
problems caused by this modification, please report.

- Stefan
  2453   31 Jan 2023 Lukas GerritzenSuggestion"Soft interlock" possible?
Is it possible to impose requirements on certain output variables in an interlock-like fashion? For example: "As long as the temperature exceeds a certain threshold, a light switched by a relay cannot be turned on."

A workaround would be to set an alarm on that variable and call a script which turns the light back off, but that might not be ideal in certain scenarios. For safety-critical situations, a PLC would be preferred, but I am missing an option between those two.
  2454   31 Jan 2023 Stefan RittSuggestion"Soft interlock" possible?
> Is it possible to impose requirements on certain output variables in an interlock-like fashion? For example: "As long as the temperature exceeds a certain threshold, a light switched by a relay cannot be turned on."
> 
> A workaround would be to set an alarm on that variable and call a script which turns the light back off, but that might not be ideal in certain scenarios. For safety-critical situations, a PLC would be preferred, but I am missing an option between those two.

No, interlocks of that kind are not implemented in midas. And that is for a good reason. Interlocks are critical, so one must be sure 100% that they are working. This cannot be done with complex software such as midas. You have to use dedicated hardware for that. 
Most people use a PLC controller which is made for that. Midas is then only used to read and display the status of the interlock controller.

Stefan
  834   06 Sep 2012 shaunBug Report"cannot find recent history file"
Hi, when attempting to access a history window the following message is repeated
over and over in the MIDAS message log:

Thu Sep 6 11:37:16 2012 [mhttpd,ERROR] [history.c:886:hs_count_events,ERROR]
cannot find recent history file
Thu Sep 6 11:38:16 2012 [mhttpd,ERROR] [history.c:886:hs_count_events,ERROR]
cannot find recent history file
Thu Sep 6 11:38:16 2012 [mhttpd,ERROR] [history.c:886:hs_count_events,ERROR]
cannot find recent history file
Thu Sep 6 11:39:16 2012 [mhttpd,ERROR] [history.c:886:hs_count_events,ERROR]
cannot find recent history file
Thu Sep 6 11:39:16 2012 [mhttpd,ERROR] [history.c:886:hs_count_events,ERROR]
cannot find recent history file

It appears to be related to attempting to display a history graph that includes
some time periods that have no recorded history data. When I zoom in so that the
whole graph has data the error message goes away.

The graph displays fine either way, so this error message seems useless. Is
there a way to suppress it?

Thanks
Shaun
  186   16 Dec 2004 Konstantin OlchanskiInfo"cd /" in ss_daemon_init(), was- Commit local TWIST modifications
> > - system.c: do not chdir("/") in ss_daemon_init()- it prevents us from ever
> >   getting core dumps from midas daemons.
> 
> The chdir("/") is from one of the unix text books. They say you HAVE to do it. If you start a
> daemon on an NFS file system, you cannot unmount that file system as long as the daemon is
> running.

Right, I remember this NFS problem from a while back.

This problem does not exist in the current crop of Linux systems (since Red Hat 7.3 at least) - they
either kill off all user programs or use "umount -f" and "umount -l".

"umount -l" works in any case to unmount a "busy" filesystem.

For systems where the NFS problem does still exist, one should do this: "mlogger -D" becomes "(cd /; mlogger -D)".

So I suspect that the "cd /" advice from the unix programming book is no longer as necessary
as it used to be. (Perhaps a better advice would have been to "cd /tmp", so we could still get
core dumps from non-root daemons).

K.O.
  294   17 Aug 2006 Konstantin OlchanskiBug Report"double" values are truncated
The mhttpd ODB displays and mhist truncate values of "float" and "double"
floating point variables to 6 digits. In reality, "float" has 7 significant
digits and "double" has 16. I recommend that db_sprintf() in odb.c be changed to
read this:

      case TID_FLOAT:
         sprintf(string, "%.7g", *(((float *) data) + index));
         break;
      case TID_DOUBLE:
         sprintf(string, "%.16g", *(((double *) data) + index));
         break;

K.O.
  295   17 Aug 2006 Stefan RittBug Report"double" values are truncated
> The mhttpd ODB displays and mhist truncate values of "float" and "double"
> floating point variables to 6 digits. In reality, "float" has 7 significant
> digits and "double" has 16. I recommend that db_sprintf() in odb.c be changed to
> read this:
> 
>       case TID_FLOAT:
>          sprintf(string, "%.7g", *(((float *) data) + index));
>          break;
>       case TID_DOUBLE:
>          sprintf(string, "%.16g", *(((double *) data) + index));
>          break;
> 
> K.O.

I had there

      case TID_FLOAT:
         if (ss_isnan(*(((float *) data) + index)))
            sprintf(string, "NAN");
         else
            sprintf(string, "%g", *(((float *) data) + index));
         break;
      case TID_DOUBLE:
         if (ss_isnan(*(((double *) data) + index)))
            sprintf(string, "NAN");
         else
            sprintf(string, "%lg", *(((double *) data) + index));
         break;

so I assumed that "%g" takes care of the maximal resolution. But apparently it does
not. So I changed it as you proposed.
  312   16 Oct 2006 Exaos LeeBug Fix"make install" error on MacOS 10.4.7, svn 3366
While executing "make install" under MacOS 10.4.7, you may encounter errors about "dio". It is the 
problem of "Makefile". I did some change to it and attach the diff file here.
Attachment 1: Makefile.diff
461,463c461,463
< 	chmod +s $(SYSBIN_DIR)/dio
< 	chmod +s $(SYSBIN_DIR)/mhttpd
< 	chmod +s $(SYSBIN_DIR)/webpaw
---
> 	if [ -f $(SYSBIN_DIR)/dio ]; then chmod +s $(SYSBIN_DIR)/dio ; fi
> 	if [ -f $(SYSBIN_DIR)/mhttpd ]; then chmod +s $(SYSBIN_DIR)/mhttpd; fi
> 	if [ -f $(SYSBIN_DIR)/webpaw ]; then chmod +s $(SYSBIN_DIR)/webpaw; fi
521c521
< 	@for i in mserver mhttpd dio ; \
---
> 	@for i in mserver mhttpd; \
525a526,528
> ifeq ($(OSTYPE),linux)
> 	install -v -m 755 $(BIN_DIR)/dio $(SYSBIN_DIR)
> endif
527,528c530,531
< 	chmod +s $(SYSBIN_DIR)/dio
< 	chmod +s $(SYSBIN_DIR)/mhttpd
---
> 	if [ -f $(SYSBIN_DIR)/dio ]; then chmod +s $(SYSBIN_DIR)/dio; fi
> 	if [ -f $(SYSBIN_DIR)/mhttpd ]; then chmod +s $(SYSBIN_DIR)/mhttpd; fi
ELOG V3.1.4-2e1708b5