I have a device running TwinCAT/BSD.
Following section 5 the manual for TwinCAT/BSD I have successfully managed to install the TF6250 package. After updating the firewall rules I have confirmed that I am able connect and issue modbus tcp requests successfully using the Default Configuration from section 4.3 of the TF6250 manual.
My project requires mapping that is different from the default (i.e to the %Q registers rather than %M). Normally (when not not using TwinCAT/BSD) I would be able to edit my mapping via the Modbus TCP Configurator, but there does not appear to be an equivalent tool contained in the package for TwinCAT/BSD.
I have tried copying the mapping files that I would have created in the configurator into the Server directory with no luck. Are you able to tell me how my mapping can be updated in the TwinCAT/BSD environment?
If relevant:
TwinCAT Build: 3.1.4024.19
TC/BSD: 12.2.9.1,2
TF6250-Modbus-TCP: 2.0.1.0_1
pkg repo: https://tcbsd.beckhoff.com/TCBSD/12/stable/packages
I spoke with Beckhoff support who told that TF6250 expects the xml file with the configuration here: /usr/local/etc/TwinCAT/Functions/TF6250-Modbus-TCP/TcModbusSrv.xml
I tested this and it appears to work so all you need to do;
Create the mapping file as per normal (e.g using the windows tool) and copy the file there.
Reboot the device to load the configuration from the file.
Related
I created a simple project using ATG 10.2 .I want to know how to deploy it in weblogic. Please provide detailed procedure with screenshots,if possible.
To provide a 'detailed' procedure is beyond the scope of what StackOverflow is trying to provide. That said, if you have an understanding of the Weblogic Management Console you should be able to follow these steps to setup your initial deployment:
Create a Server
1.1 Specify a server name (eg. commerce) and the port number this server will run on (eg. 8180). Select it as a 'Stand-alone server'.
1.2 Once created go to Configuration > Server Start for the newly created server and modify the 'Arguments' block and include the following setings (assuming you are running windows, for Unix update your own paths)
-Datg.dynamo.data-dir=c:\ATG-Data -Datg.dynamo.server.name=commerce -d64 -XX:ParallelGCThreads=8 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Xms1152m -Xmx2048m -XX:NewSize=128m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=256m
1.3 Save your Server
Create DataSources
2.1 In the Console click on 'Services > Data Sources'
2.2 Create 'New' datasources for each of your connections. As a minimum you will need connections for ATGSwitchingDS_A, ATGSwitchingDS_B (Assuming you are doing switching datasources) and ATGProductionDS. These names should match your JNDI names in your property files. Remember to specify the 'commerce' server as the target for each of the datasources.
Create Deployment
3.1 Assuming you've already built your EAR (eg. ATGProduction.ear) and it is available in c:\deployments you need to create a deployment in Weblogic. You need to create the deployment in the console and specify the target as 'commerce'. Once done you need to also 'start serving requests' on the deployment.
Start Server
You should now be able to see your server running on port 8180 with the log files being written to c:\ATG-Data\servers\commerce\logs.
If after this things aren't running, post specific questions about your issues and someone here might be able to help you.
Can i get config for all adapters at one place ? For example, i need store connection strings, httpserver addresses that needed across my mobilefirst server.
Mobilefirst version 8.0.
Thank you for advance!
In MobileFirst Foundation 8.0 you have the following options:
If using JavaScript adapters:
Edit the connectivity settings from the MobileFirst Console,
Or create a config file and use Maven commands (or the MobileFirst CLI in an upcoming CLI update), or other tools, to push the file to each adapter that requires that same set of connection settings.
Using this method there is no downtime to the server.
See the "Pull and Push Configurations" topic here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/adapters/javascript-adapters/
Customized adapter properties can be shared using the adapter configuration file found in the Configuration files tab.
To do so, use the pull and push commands described below. For the properties to be shared, you need to change the default values given to the properties.
Replace the DmfpfConfigFile placeholder with the actual value, for example: config.json. Then, run the command from the root folder of the adapter Maven project:
To pull the configurations file - mvn adapter:configpull -DmfpfConfigFile=<path to a file that will store the configuration>.
To push the configurations file - mvn adapter:configpush -DmfpfConfigFile=<path to the file that stores the configuration>.
If using Java adapters,
You can add JNDI properties to the server.xml of your application server, and using the configurationAPI (getServerJNDIProperty) you can read those properties in each of your adapters. However note that by using server.xml this will incur a downtime whenever you will want to update your list of connection properties.
We have a Windows Server 2012 64bit + Weblogic 12c setup. The AdminServer requires a higher PermSize when being used with a 64bit OS, thus we need to modify the "setDomainEnv.cmd" (as described in other questions here on stackoverflow).
When starting the AdminServer through the usual "startWeblogic.cmd" script, it uses the settings in "setDomainEnv.cmd" that sets the PermSize etc. successfully, but when using NodeManager "startServer()" command, it does not.
I read something in the documentation about the fact that one can control the parameters that are loaded on startup of a managed server (with NodeManager), but I did not find the right way to do it.
I would hope that we can achieve a consistent behaviour when starting a managed server (and the AdminServer) through NodeManager or manually.
Any ideas?
UPDATE:
I checked what's going on when starting managed server and(!) in comparison what's going on when starting the AdminServer. Result: the AdminServer process (it starts a 'javaw.exe' instance in contrast to a 'java.exe' instance for a managed server) never get's passed ANY parameters set in the setDomainEnv.cmd script.. it's basically full of Oracle internal parameters.
To me all this looks completely messed up and inconsistent. In addition to this I found an issue reported by Oracle that mystically talks about setting environment variables when running on a 64bit OS (see headline "Developer ZIP Distribution Fails on Windows 64-bit and Linux 64-bit"):
https://docs.oracle.com/cd/E24329_01/doc.1211/e26593/issues.htm#WLSRN238
I have idea if this applies to my version or not, since the version I downloaded does not say "developer" version, it basically was the primary weblogic download for the latest release.
The question that comes to my mind is this: what is the expected way of starting the AdminServer if not using "startServer"? Is there a bug that nobody cares about, since it is usually done differently? I am really disappointed to how confusing this rather simple topic evolves when starting to read Oracle documentation: it simply does not say anything about it at all.
Command line that is triggered when starting the AdminServer through "startServer()" command:
C:\PROGRA~1\Java\JDK17~1.0_6\jre\bin\javaw.exe -classpath "C:\PROGRA~1\Java\JDK17~1.0_6\jre\lib\rt.jar;C:\PROGRA~1\Java\JDK17~1.0_6\jre\lib\i18n.jar;C:\PROGRA~1\Java\JDK17~1.0_6\lib\tools.jar;D:\Oracle\Middleware\wlserver\server\lib\weblogic_sp.jar;D:\Oracle\Middleware\wlserver\server\lib\weblogic.jar;D:\Oracle\Middleware\oracle_common\modules\net.sf.antcontrib_1.1.0.0_1-0b3\lib\ant-contrib.jar;D:\Oracle\Middleware\wlserver\modules\features\oracle.wls.common.nodemanager_2.0.0.0.jar;D:\Oracle\Middleware\oracle_common\modules\com.oracle.cie.config-wls-online_8.1.0.0.jar;D:\Oracle\Middleware\wlserver\common\derby\lib\derbyclient.jar;D:\Oracle\Middleware\wlserver\common\derby\lib\derby.jar;D:\Oracle\Middleware\wlserver\server\lib\xqrl.jar" "-Djava.runtime.name=Java(TM) SE Runtime Environment" -Dpython.cachedir=C:\Users\ADMINI~1\AppData\Local\Temp\2\wlstTempAdministrator -Djava.protocol.handler.pkgs=weblogic.utils|weblogic.utils|weblogic.utils -Djava.vm.version=24.65-b04 "-Djava.vm.vendor=Oracle Corporation" -Djava.vendor.url=http://java.oracle.com/ -Dpath.separator=; "-Djava.vm.name=Java HotSpot(TM) 64-Bit Server VM" -Dweblogic.RootDirectory=D:\Oracle\Middleware\user_projects\domains\test1234\. "-Djava.vm.specification.name=Java Virtual Machine Specification" -Djava.runtime.version=1.7.0_67-b01 -Djavax.rmi.CORBA.UtilClass=weblogic.iiop.UtilDelegateImpl -Djava.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment -Djava.endorsed.dirs=C:\PROGRA~1\Java\JDK17~1.0_6\jre\lib\endorsed -Dos.arch=amd64 -Djava.io.tmpdir=C:\Users\ADMINI~1\AppData\Local\Temp\2\ -Dline.separator=
"-Djava.vm.specification.vendor=Oracle Corporation" -Djava.naming.factory.url.pkgs=weblogic.jndi.factories:weblogic.corba.j2ee.naming.url "-Dos.name=Windows Server 2012 R2" -Dprod.props.file=D:\Oracle\Middleware\wlserver\.product.properties -Dorg.omg.CORBA.ORBSingletonClass=weblogic.corba.orb.ORB -Djava.library.path=C:\PROGRA~1\Java\JDK17~1.0_6\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;;D:\Oracle\Middleware\wlserver\server\native\win\x64;D:\Oracle\Middleware\wlserver\server\bin;D:\Oracle\Middleware\oracle_common\modules\org.apache.ant_1.9.2\bin;C:\PROGRA~1\Java\JDK17~1.0_6\jre\bin;C:\PROGRA~1\Java\JDK17~1.0_6\bin;D:\Oracle\product\12.1.0\dbhome_1\BIN;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WINDOW~1\v1.0\;C:\PROGRA~2\VISUAL~1\bin;C:\PROGRA~1\doxygen\bin;C:\PROGRA~1\TORTOI~1\bin;C:\PROGRA~2\WINDOW~4\8.0\WINDOW~1\;C:\PROGRA~1\MICROS~1\110\Tools\Binn\;D:\Oracle\Middleware\wlserver\server\native\win\x64\oci920_8;. "-Djava.specification.name=Java Platform API Specification" -Djava.class.version=51.0 -Dorg.omg.CORBA.ORBClass=weblogic.corba.orb.ORB -Dos.version=6.3 -Djavax.rmi.CORBA.PortableRemoteObjectClass=weblogic.iiop.PortableRemoteObjectDelegateImpl -Djava.awt.printerjob=sun.awt.windows.WPrinterJob -Djava.specification.version=1.7 -Djava.class.path=C:\PROGRA~1\Java\JDK17~1.0_6\lib\tools.jar;D:\Oracle\Middleware\wlserver\server\lib\weblogic_sp.jar;D:\Oracle\Middleware\wlserver\server\lib\weblogic.jar;D:\Oracle\Middleware\oracle_common\modules\net.sf.antcontrib_1.1.0.0_1-0b3\lib\ant-contrib.jar;D:\Oracle\Middleware\wlserver\modules\features\oracle.wls.common.nodemanager_2.0.0.0.jar;D:\Oracle\Middleware\oracle_common\modules\com.oracle.cie.config-wls-online_8.1.0.0.jar;D:\Oracle\Middleware\wlserver\common\derby\lib\derbyclient.jar;D:\Oracle\Middleware\wlserver\common\derby\lib\derby.jar;D:\Oracle\Middleware\wlserver\server\lib\xqrl.jar -Djava.vm.specification.version=1.7 -Dweblogic.management.GenerateDefaultConfig=false -Djava.home=C:\PROGRA~1\Java\JDK17~1.0_6\jre "-Djava.specification.vendor=Oracle Corporation" -Dawt.toolkit=sun.awt.windows.WToolkit "-Djava.vm.info=mixed mode" -Djava.version=1.7.0_67 -Djava.ext.dirs=C:\PROGRA~1\Java\JDK17~1.0_6\jre\lib\ext;C:\Windows\Sun\Java\lib\ext "-Djava.vendor=Oracle Corporation" -Djava.vendor.url.bug=http://bugreport.sun.com/bugreport/ -Dweblogic.store.DisableDiskScheduler=true -Dpython.verbose=warning weblogic.Server
UPDATE 2:
Start the AdminServer through node manager (nmStart('AdminServer')) creates a usual "java.exe" process and starts up the AdminServer with correct memory settings. But this is even more confusing: why is "startServer()" creating a separate process (javaw.exe) with entirely different settings? Why are my settings now totally different for AdminServer? What is the "correct" way of starting the AdminServer (development/production?). Two thumbs down on this environment.
UPDATE 3:
After repeating further tests the solution of getting "startServer()" to work is basically as follows: do not worry about the node manager settings at all, edit the "startWeblogic" script directly by adding additional java options inside of it (as usual by adding -D start parameters). The reason for all this is basically that the global settings (as used by node manager) are ignored completely, see my pasted command line output.
Check the nodemanager.properties file in your Oracle install ( e.g. /opt/ora/mw/wlserver_10.3/common/nodemanager/nodemanager.properties ) and verify that these options are set:
StartScriptName=startManagedWebLogic.sh
StartScriptEnabled=true
so the nodemanager is starting your servers with the appropriate scripts. You also have to option of setting server specific start attributes via the admin console - go to:
Servers -> Server Name -> Server Start tab -> Arguments
You can fill in server specific JVM args, like -XX:MaxPermSize=4096m in this field that will be used by the nodemanager. This may be a better/easier idea than hard coding it in the setDomainEnv script.
UPDATE
Attempt issuing an nmStart() command rather than a startServer() command for the AdminServer.
startServer allows you to start a server WITHOUT the nodemanager. It uses javaw.exe to effectively background the process
nmStart allows you to start the server WITH the nodemanager - which is why you get the correct memory settings. Because the process is started via a service, it is more or less automatically backgrounded, which is why you see the normal java.exe
I have an application that was migrated from Glassfish to Weblogic, and it uses java.util.logging as logging framework.
The only way I have found to make the logs work is by editing the logging.properties file of the JVM and restart the server. This solution is awkward and gives problems because the log is written to a different file than the standard ones for weblogic, so we have to look at too many files for a log in a clustered environment. Besides, for some reason this does not work on some Windows systems.
Is there a way to keep using standard java logging to write messages to weblogic's standard log files? I tried the instructions on this page but it doesn't work either.
WebLogic Server ships with a JDK logging handler which will pick up log messages emitted from JDK logging framework and direct them into the WebLogic Server logging system.
Set the default logging level for new ServerLoggingHandler instances in logging.properties as well as adding the ServerLoggingHandler to the handlers.
handlers = weblogic.logging.ServerLoggingHandler
weblogic.logging.ServerLoggingHandler.level = ALL
http://docs.oracle.com/cd/E14571_01/web.1111/e13739/logging_services.htm#CHDBBEIJ
To direct the JDK logging framework to use the logging.properties file, the standard System property java.util.logging.config.file is used. With WebLogic Server, this can be easily accomplished by setting the JAVA_OPTIONS System property with the corresponding value.
$ export JAVA_OPTIONS="-Djava.util.logging.config.file=/Users/xxx/Projects/Domains/wls1035/logging.properties"
Some more hints here: http://buttso.blogspot.de/2011/06/using-slf4j-with-weblogic-server.html
I'm Trying to write a plugin for NotePad++ using NppScripting - a platform for writing plugins using javascript (specifically - JScript).
I was wondering if there was a way (probably via ActiveXObject) with which I could listen to a port asynchronously (specifically - I'm trying to write a CSS-X-Fire port to NPP).
I know .NET has that capability via System.Net.Sockets but I couldn't figure out a way to access it via JScript.
Any help?
If I were doing this, I would write the Socket server in .NET as a standalone EXE.
If I understand CSS-X-Fire correctly, it is a plugin to IntelliJ Idea that listens to outgoing communications from Firebug, and then updates source files appropriately. It sounds relatively simple. The .NET socket server could do this very easily.
Then, rather than expose a 2nd interface directly from the socket server to the scripting environment - like a COM object or a COPYDATA channel or something like that - I'd use the filesystem for communication. In other words, script something in NPP that polls the filesystem file for updates. When the .NET Socket server gets a message that says "Firebug just updated file X.css", the .NET Socket server can apply those updates to the filesystem file, and save changes back to the filesystem. Because the Notepad++ app polls the filesystem, it will see the updated file and reload it, picking up those saved changes. You'd need to do cursor management within N++ intelligently.
Emacs has an "auto revert mode" for this sort of thing, so the .NET CSS-X-Fire Socket server would work with emacs out of the box - no additional scripting required. Not sure if N++ has an auto-revert equivalent.
I eventually decided to use Adobe AIR to create my solution. It provides an amazing set of APIs, including a set of Socket APIs.
You can look at my solution here