I install an Orthanc Server (PACS) with WebGui, and upload a few dicoms from osirix dicom sample. I have a some problem with command findscu from package dcm4che3. When I called /findscu -c TEST#127.0.0.1:4242 -m PatientName="WRIX" , I have an error:
org.dcm4che3.net.AssociationStateException: Sta1 - Idle
at org.dcm4che3.net.State.writeAReleaseRQ(State.java:223)
at org.dcm4che3.net.Association.release(Association.java:271)
at org.dcm4che3.tool.findscu.FindSCU.close(FindSCU.java:463)
at org.dcm4che3.tool.findscu.FindSCU.main(FindSCU.java:380)
in orthanc log:
E0713 16:20:51.875545 main.cpp:180] Unknown remote DICOM modality AET: "FINDSCU"
E0713 16:20:51.875589 CommandDispatcher.cpp:776] Find requests are disallowed for the AET "FINDSCU"
E0713 16:20:51.875603 CommandDispatcher.cpp:852] DIMSE failure (aborting association): DIMSE Caller passed in an illegal association
I think I need to add in orthanc.json FINDSCU how ?
You must declare your modality FINDSCUin the DicomModalitiesoption of the configuration file of Orthanc, otherwise Orthanc will refuse to answer for security reasons. More information is available in the Orthanc Book, in the section entitled "Understanding DICOM with Orthanc".
Related
I am trying to use Xtensa cross compiler to build a simple embedded application.
And I got 2 mysterious issues.
The first issue is probably a license issue:
The Xtensa toolchain always reports below error:
License checkout failed: No such feature exists.
Feature: XTENSA_XCC_TIE
License path: 84300#xtensa03p.xxx.xxx.com:/root/xtensa/XtDevTools/install/tools/RG-2019.12-linux/XtensaTools/Tools/lic/license.dat:
FLEXnet Licensing error:-5,147
For further information, refer to the FLEXnet Licensing documentation,
available at "www.macrovision.com".
This looks like a license issue.
According to here, the -5 error code means No such feature exists. But I didn't find what 147 means. And I am not sure about how FLEXnet works. It seems to be a popular licensing mechanism.
But I can ping through the xtensa03p.xxx.xxx.com server. So I think the license server is alive.
The second issue:
When I try to check the cross compiler xt-xcc version:
/root/xtensa/XtDevTools/install/tools/RG-2019.12-linux/XtensaTools/bin/xt-xcc --version
I got below warning:
Warning: The location of this program does not match the Xtensa Tools
location specified in the Xtensa registry entry:
program prefix: /root/xtensa/XtDevTools/install/tools/RG-2019.12-linux/XtensaTools/bin/..
registry value: /root/xtensa/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools
Either the current Xtensa configuration is not properly installed or you
are using Xtensa Tools from a different location than you specified when
installing the configuration.
xt-xcc version 12.0.12
Thread model: single
I don't know where the Xtensa registry entry is. Should I modify it to match my xt-xcc installation path?
Could anyone shed some light?
I done all steps to install orocommerce on azure CentOS and nginx.
So now i got the following error after
$ ./bin/console oro:install --env=prod --timeout=900
"In ParameterBag.php line 102:
You have requested a non-existent parameter "web_backend_prefix".
Have anybody an idea?
How exactly did you get the source code (if GitHub - what repository, tag/branch, if download - what website and version)? Based on the error text it seems like it might be OroPlatform or OroCRM application, not OroCommerce.
I'm new to the Nim programming language, and coming from a Lua background, it excited me to find out that there is a module for adding Lua bindings to Nim.
I installed Nimble (Nim's package manager) for Windows and executed "nimble install lua" to download and install the correct module. Upon trying to import it and compile the source, this happened:
C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest>nim c -r "C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest\main.nim"
Hint: system [Processing]
Hint: main [Processing]
Hint: lua [Processing]
CC: main
CC: lua_lua
Hint: [Link]
Hint: operation successful (10698 lines compiled; 1.262 sec total; 16.163MB; Debug Build) [SuccessX]
could not load: lua(|5.1|5.0).dll
Error: execution of an external program failed: 'c:\users\ashley\desktop\stuff\coding\nim\projects\luatest\main.exe '
I have Lua 5.1 already installed with the proper entries in PATH. It's located in Program Files (x86). The directory contains a dll called lua5.1.dll. I tried looking up the error on Google, but there were no results that helped. What could be the problem?
On Windows you can put the library at the same place as the generated binary. In this case the file should be called lua.dll, lua5.1.dll or lua5.0.dll. Also make sure that the library and binary are both for the same system architecture, either x86 (32bit) or x86-64 (64bit).
I need help understanding an error why I'm seeing an error.
The feature api is already enabled with the correct ApiListener object, and Api logs are being updated in /var/lib/icinga2/api/log/current .
But I'm getting this error when I restart icinga2:
Error: Error while evaluating expression: The type 'ApiUser' is unknown: in /etc/icinga2/conf.d/api-users.conf: 1:0-1:20
I'm running version r2.3.10-1 of Icinga2 on Ubuntu.
Can someone explain what the problem is?
You are probably mixing the current snapshot packages with the released stable versions. The 'ApiUser' object is part of the upcoming Icinga 2 v2.4 release and only available in git master (and therefore snapshot packages as well as docs). The stable 2.3.x tree does not have that kind of configuration object type and therefore bails out with an error.
Remove that file or its content, you don't need it for 2.3.x.
I'm on TCL 8.5 (can't upgrade) and running version 2.7.7 of the HTTP package. I'm calling a library which appears to be using the following http::geturl command to download an image which has been gzipped:
http::geturl $url -headers {Accept-Encoding gzip}
and I'm getting this error:
invalid command name "zlib"
Searching on the web, I could only find this reference to the bug which basically recommends stopping sending Accept-Encoding gzip, which I can't do (nor can I upgrade to 8.6) http://sourceforge.net/p/tcl/bugs/4784/
My question is: is there any 8.5 workaround for this issue? Is there a way to stop this library from sending the "Accept-Encoding gzip" header?
The issue is that the code believes you've got the zlib package (which supplies the zlib command) available, and so turns on support for gzip-compressed streams. The simplest fix in your code is to do:
package require zlib
So long as this happens before you call into the code that does the http::geturl, this should be enough.
If you don't have the package (in which case you'll get a clear failure from the package require) then you've hit a bug either where the soft dependency code in the http package is getting it wrong when building the request headers, or in the server which is sending gzipped data despite not being asked for it. The code pointed to from TIP #234 (i.e., the SVN repository at http://svn.scheffers.net/zlib) contains the source for a version of the zlib package, in particular it's the version that formed the starting point for the built-in support in Tcl 8.6, but I think it only uses Tcl 8.5 APIs.
Unhelpfully, there are several versions of the zlib package around; this is one of the messiest Tcl packages to acquire, alas.