Posts by blub_smile

Hi
Yeah that should work. Also I havent tried it yet it, is supported.
greetz

So from what I understand you now have one single Conquest MAG folder of xray data where the "old" AND "new" xray studies are stored together.

1) If I am assuming that this is correct you now have to point conquest MAG0 to that specific directory (if you havent done that already)

I guess that you probablyhave already done step 1) cause you said new data is accessibel (old stuff not, because you have copied/drag and dropped it into new folder etc.), in this case you have to do a "regen" for the MAG device which is set to that specific folder containing old and new studies.

..then ist should be done..

good luck
Stephan

mhh sorry I think I cannot help you that one.
But to get more info you could increase the dubug level get more information.
greetz

Hi

I usualle get this "Error on Load" message when I drag and drop file over a network share or network drive into the Conquest user interface.

One way for you to transfer the files is either send them to Conquest via a dicom software/workstation in small amounts - lets say 3 months of data at once etc... .

You could also make a conquest serve on the old computer, point mag devices to the data storage and re-initialize th e DB, then syncing it with the new server.
greetz

Hi Chris

Well with 10.000 img per year it schould be very easy once you have set up you storage disc and DB.
I do not know of I2View, but we use Efilm (it should work anyway). If desired, Conquest stores all incoming images compressed (as we do) in a NKI lossless compression with file extension "*.v2". This file format, as far as I know, cannot directly (from this disc) be read by ANY other software.
But within conquest any receiving client, such as efilm, can be configured to receive images either uncompressed or compressed (so if EFILM is configured to receive onnly "uncompressed" the conquest server de-compresses any image before sending it to the client (can be done for any client) - so it only depends on what your client software is capable of :-). - it may requiere some testing
greetz

Hi!

Well setting up Conquest so that "it worked" took about 1 hour with MySQL.
Configuring all AE Titles and foreward rules took quite some time..lets say "about a work day" until it worked the way we wanted it to (keep in mind we had no idea of conquest before - so thats quite quick, I think).
MySQL tweaking can be a pain in the ass.....but in the beginning it will work just fine - it just gets more important the biger your DB gets (MySQL ini setting and DB maintnance). At the moment we have around 45.0000 CT / MR studies using ~1.2TB (compressed) with a DB-size of ~4,5GB.

The only major drawback I see is that if conquest cannot handle a receiving study it wont be saved and you will have an entry in the log but no email etc.. . . So if you do not check the log on a regular basis it might happen that some studies are missing nad you have to import them manyualy from CD/DVD or where ever you have them archived.
greetz

It seems that conquest cannot connect to sql - this can have the following reasons:

- wrong IP or port for SQL server
- wrong user name and/or pasword
- database "conquestpacs_s2" does not exist
- insufficient rights for user "conquest" within SQL or for the selected database (for example only right to "read")

greetz

Hi!

We are currently planing a new Conquest Server which should be capable of holding the data for about 10 years.
Though this is a difficult task I could need some help and suggestions

This is what we got so far:

LianLi cube case

Tyan Server Board
Xeon Quad Core 2,66GHZ
8GB RAM ECC Kingston

2x 3Ware 16 Port Sata RAID Controller

6x SATA Backplane IcyDock MB455SPF

2x Seagate SAS 15k rpm 147GB as System Drive (RAID 1)
2x Seagate SAS 15k rpm 300GB as database drive (RAID 1)

13x Hitachi 1TB drive as storage
13x Seagate 1TB drive as storage

storage drives configured as RAID 6 with one hot spare drive.

Windows Server Enterprise 64bit

What I am totally not sure about is the power supply, should I go for a redundant server modell
or would an Enenermax Galaxy with 1000W be sufficient (has the advantage of 18 connectors!) - we do not rely on the server beeing up 24/7, we do also archive all of our studies on DVD.

So what do you think? Is the setup appropiate or would you suggest something different?

Best regards
Stephan

Hi!
I dont know where the MS SQL database files are stored, that can depend how the system has been set up - but you should find this information in the SQL management tool.
When it comes to the x-ray images you do not have to make any backup as long as you dont change/delete anything in the archive directory.
If you totally screw up the DB you can still regenerate a new databse from the x-ray image archive itsself - this takes while though

Kepp in mind what skrani said about the MS SQL express limitations when it comes to the 4GB DB limit - if thats the prob its totally not your fault :-)!

Otherwise try get the guy who set the whole system up
greetz

Hi!
Changing the DICOM providers in the Conquest config should as far as I know not produce such an error!?

So from what I understand of the log file there seem to be two Database problems of some kind.

1) ***Error saving to SQL

2) Could not allocate space for object 'DICOMImages' in database 'XRAY' because the 'PRIMARY' filegroup is full

1) We had this problem with MySQL installations and it was a windows related problem - [url]http://www.image-systems.biz/p…t=621&highlight=error+sql[ßurl]

- maybe its the same issue (not sure about it)

2) The installation is a MS SQL do I get that right? - If so there is some kind of allocation problem concerning the file(s) that store the table information on the hard drive.
It could either be that the hard drive is full and the database files cannot get any larger OR the autoincrement (autogrow) settings is turned off etc - some problem of this kind.

Do you hvae the error log from MS SQL? - that could maybe be more helpfull.
greetz
Stephan

@ Marcel:
64bit: I know that ther server SW is only 32bit. It got the idea cause of the mysql process. When the server is runngin such a huge DB it could make sense to keep as many tables in mem. as possible - and in 32bit systems there is a max with about 3,25GB im Ram with PAE enabled - thats how I got the idea

MySQL issue: the registry patch is enabled. I am very sure that it has something to do with the system beeing overloaded for a few seconds.

Hi
I would go for a server running Windows Server 2003 (64bit ?) and MySQL or MS SQL.
We are currently using MySQL and it is running fine, except some random "could not connect to databse issues" - but this is probably because we are also using the server to render and burn patient disc.
As for the drive config, conquest can be set to use multiple MAG Devices (paths) which can be located on numerous discs, and will be filled up one after another - so there is no need for repointing when the volume fills up.
On the other side you could simply build a RAID6 volume of 10-18TB or more, depending on whether you go for a server tower or rack, this giving you redundancy over two drives at a time. If you then configure 1 or more hot spare drives you should be ok I think ;-).
To have a faster system when having many images it is usefull to have the database file on a fast disc with 10 or 15000rpm and lots of RAM - with RAM prices at an all time low why not go for 8GB or 16GB
The storage path can be configured pretty much the way you like, we are using something like this: /Archive/modality/year/studyUID
greetz

Hi,
as snalbansed already told you it takes a huge ammount of space ;-).
if you store a cardiac ct including some recon jobs you can even end up with around 14 to 15000 images, that would result in 7GB...ouch :-).
So it pretty much depends on what images you want to archive.
We currenty do archive our abd pelvis exam only in recon images of 5mm (I think )to save space.
So for exams you do recon jobs on, like cardia cts, it makes sense to only archive the "good" recons, and for other studies it just depends what you consider to be good enough.
greetz

Hello Marcel

When I try to sent studies to Vitrea from Conquest user interface I get the message "remote dicom error", when making queries to Vitrea I get the message "association lost".
Vitrea uses two AEs 1) VITREA to receive studies, 2) VITREASERVER to respond to queries etc. Both AEs are entered into Conquest, it is in fact very wired. Other workstations can send to Vitrea and make queries just not conquest.
Nevertheless we are getting a new version of vitrea in the next weeks because it is very unstable. maybe this will solve the problem
greetz

Hi

Option 1) impossible. These are normal CT studies. I can send any study to Vitrea via eFilm without any problem.

Option 2) could be, how can I verify / check this?

Option 3) I already checked that a couple of times, port and AE are entered correctly.

ohh no thats a misunderstanding
Host 1: PACS
Host 2: VITREA

no spaces

Hello

I have just checked the AEs on both machines. They are correct, both AEs are written in capitals letters like this:
PCAS VITREA and are listed correct in both applications.
We still cannot receive any studies from our pacs on the vitrea WS.
greetz

Hi,
I will verify the ports once more as soon as possible, just to make sure.
I have also seen that many problems are firewall related, therefore I always disable the windows FW. Though this workstation was setup by Toshiba I will check that. We currently do not have any other FW soft/hardware which might interfere here.
The Toshiba engineer made a "DICOM snif or TCAT grab" which revealed that somehow the requested dataset does not exist on the pacs - which is a little weired !?

Toshiba info:

Below the reply from the PACS on our c-move request:

------------P-DATA-TF PDU------------
PDU length: 134 0x00000086
PDV length: 130 0x00000082
Presentation context-ID: 1 0x01
Message Control Header 0x03 Last Command Message
---------------------------------------------------------------------------------------------
! Grp Tag Attribute Name VR Length Value
---------------------------------------------------------------------------------------------
[CMD] (0000,0000) Group Length UL 4 "116 0x00000074"
[CMD] (0000,0002) Affected SOP Class UID UI 28 "1.2.840.10008.5.1.4.1.2.2.2 "
[CMD] (0000,0100) Command Field US 2 32801 0x8021 C-MOVE-RSP
[CMD] (0000,0120) Message ID Being Responded to US 2 "1 0x0001"
[CMD] (0000,0800) Data Set Type US 2 "257 0x0101"
[CMD] (0000,0900) Status US 2 "49157 0xC005"
[CMD] (0000,1020) Number of Remaining Sub-operat US 2 "0 0x0000"
[CMD] (0000,1021) Number of Completed Sub-operat US 2 "0 0x0000"
[CMD] (0000,1022) Number of Failed Sub-operation US 2 "0 0x0000"
[CMD] (0000,1023) Number of Warning Sub-operatio US 2 "0 0x0000"

The line in bold tells that there is no data set present (value: 257 0x0101), which means that the data that we request is not present on the PACS, which is off course a bit odd since we selected it from a list just sent to us by the same PACS.

So, any ideas !?

greetz

Hello,
I am very sure that AE and IP are ok, because that is what we have triple checked and even a Toshiba technician looked over the config.
We even added the Vitreaserver AE which is usually used to query the Vitrea WS FROM other PCs - of course that was not the problem ;-).
All other WS do fine with Vitrea and the PACS, just those two wont work - somehow :-(.
Below you will find the Conquest debug info, maybe it will help.
There was one thing in tge Debug Info tah was bothering me: somewhere in the Debug info VITREA has port 1234, which is definitly not true, it is set to 3303. After I discovered that we changed config to that port but with no success.

Debug Info:

17.08.2007 16:20:14 [PACS] UPACS THREAD 1: STARTED AT: Fri Aug 17 16:20:13 2007
17.08.2007 16:20:14 [PACS] A-ASSOCIATE-RQ Packet Dump
17.08.2007 16:20:14 [PACS] Calling Application Title : "VITREA "
17.08.2007 16:20:14 [PACS] Called Application Title : "PACS "
17.08.2007 16:20:14 [PACS] Application Context : "1.2.840.10008.3.1.1.1"
17.08.2007 16:20:14 [PACS] Number of Proposed Presentation Contexts: 1
17.08.2007 16:20:14 [PACS] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.2"
17.08.2007 16:20:14 [PACS] Server Command := 0021
17.08.2007 16:20:14 [PACS] C-Move Destination: "VITREA"
17.08.2007 16:20:14 [PACS] 0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.2.2.2"
17.08.2007 16:20:14 [PACS] 0000,0100 2 US CommandField 33
17.08.2007 16:20:14 [PACS] 0000,0110 2 US MessageID 1
17.08.2007 16:20:14 [PACS] 0000,0600 6 AE MoveDestination "VITREA"
17.08.2007 16:20:14 [PACS] 0000,0700 2 US Priority 0
17.08.2007 16:20:14 [PACS] 0000,0800 2 US DataSetType 256
17.08.2007 16:20:14 [PACS] (QualifyOn) (mapped) IP:ITREA, PORT:1234
17.08.2007 16:20:14 [PACS] MyStudyRootRetrieveGeneric :: SearchOn
17.08.2007 16:20:14 [PACS] 0008,0052 6 CS QueryRetrieveLevel "STUDY "
17.08.2007 16:20:14 [PACS] 0008,0054 6 AE RetrieveAETitle "VITREA"
17.08.2007 16:20:14 [PACS] 0020,000d 58 UI StudyInstanceUID "1.2.392.200036.9116.2.6.1.48.1214859555.1187149001.137560"
17.08.2007 16:20:14 [PACS] Query On Image
17.08.2007 16:20:14 [PACS] Issue Query on Columns: DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceName
17.08.2007 16:20:14 [PACS] Values: DICOMStudies.StudyInsta = '1.2.392.200036.9116.2.6.1.48.1214859555.1187149001.137560' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
17.08.2007 16:20:14 [PACS] Tables: DICOMImages, DICOMSeries, DICOMStudies
17.08.2007 16:20:14 [PACS] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies
17.08.2007 16:20:14 [PACS] Columns : DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceName
17.08.2007 16:20:14 [PACS] Where : DICOMStudies.StudyInsta = '1.2.392.200036.9116.2.6.1.48.1214859555.1187149001.137560' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
17.08.2007 16:20:14 [PACS] Order : (null)
17.08.2007 16:20:14 [PACS] Records = 361
17.08.2007 16:20:14 [PACS] Number of Images to send: 361
17.08.2007 16:20:16 [PACS] Host 'VITREA' did not accept the connection
17.08.2007 16:20:16 [PACS] C-Move (StudyRoot)
17.08.2007 16:20:16 [PACS] UPACS THREAD 1: ENDED AT: Fri Aug 17 16:20:16 2007
17.08.2007 16:20:16 [PACS] UPACS THREAD 1: TOTAL RUNNING TIME: 3 SECONDS

Hi!
Is anyone using Conquest with Vital Images Vitrea Workstation succesfully?
We cannot retrieve any studys from our conquest pacs by the vitrea workstation. It is possible to make querries and then select a study, but after selecting retrieve we get the error message " DICOM Retrieve Error".
Conquest says "host vitrea did not accept the connection" ( I will post the debug log tomorrow), any ideas or similar experiences!?
greetz