Has anyone successfully talked profibus from a .NET application?
If you did, what device/card did you use to accomplish this, what was the application, and did you use any kind of preexisting or available code?
We've not used Profibus, but have used DeviceNET (another CAN based protocol), Ethernet/IP and ControlNet which all have similar challenges.
We've been doing this since the late 1990's and therefore rely mainly on our own generated code using off-the-shelf hardware. The companies that have shown longevity during that period that I remember are:-
AnyBus (HMS, www.anybus.com) we've recently started using their gateway products as we can place fieldbus interfaces close to the hardware and then communicate over normal Ethernet (usually using Ethernet/IP www.odva.org). This has the advantage of separating hardware and PC using only a network cable. The Ethernet/IP .NET classes were written by ourselves as nothing much was on the market at the time. I'm sure a quick google search would find suitable class libraries
SST (www.mysst.com) have had fieldbus interfaces for more than a decade. The last SST card we used for DeviceNET still only had VB6 sample code. A good selection of fieldbus support and different form-factors e.g. PC104, PCI, PMCIA
Beckhoff/Wago (www.beckhoff.com, www.wago.com) we typically use Beckhoff for the I/O more than the interface cards but again a company that has been around a long time. They also have products that support exposing using OPC (another way for you to get I/O information without directly communicating with the hardware/devicedrivers)
I suggest not using OPC interfaces to the hardware directly (it’s OK for communication using PC (.NET)->PLC->Profibus) as you need to ensure that the control system responds to loss of control from your .NET application. I’m assuming that you are needing a profibus Master here (not a slave), so as long as your control system is intrinsically fail safe, then loss of communication should mean the control system enters an "Idle" state and therefore most of the I/O will return to the fails safe state.
We also try to ensure that we do not put safety related code in .NET. Most of our .NET code is userinterface from a PLC, but in some places we do control the fieldbus directly but ensure hardware interlocks will prevent un-safe operation, either using safety switches/relays or a small PLC with the the task of interlocking only. And above all make the system fail-safe! Loss of comms from the .NET code should shutdown the automation to the fail-safe state.
We have used Steeplechase to connect to our profibus to our automated pick system.
http://www.phoenixcontact.com/automation/32131_31909.htm
Try this: http://libnodave.sourceforge.net
Related
Segger allow you to obtain a license for using their JLink SDK.
I am using it to create tooling to allow examination of the state of a new (not yet commercially available) SoC microprocessor that contains multiple cores (multiple ARM cortex M cores and DSPs) with SWD debug H/W.
Segger include a GDB server in their normal software download which can definitely access any single core from a single process.
I do not think Segger makes their SDK UM08002 documentation and code samples public but it demonstrates being able to access a single core (which works fine for me).
All the SDK really is is a set of headers and documentation that allow you call into the already distributed SEGGER JLink dll's (the dll's in the normal software download prompts you for auto updating) so there is no magic happening in the SDK itself; but it is licensed so I can't post any of it here.
What I do not understand is what dll calls must be made to access multiple cores sequentially from within a single process using the SDK.
Do I:
Disconnect and reconnect from the SEGGER every time I wish to access a different core
Can I switch between cores somehow without opening & closing the JLink connection
Can I leave the cores halted when switching between cores so the device doesn't 'run off' while I'm looking elsewhere
Will the core HW & SW debug points remain set & get triggered if I'm looking at a different core and allow me to discover this when I look back at a hopefully now halted core in question? (This may be core implementation dependant of course)
Short answer
No, sort of.
Long answer
The Segger JLink dll API is a single target per process API, so that means you can't start talking to another core while the process global state held by the dll is configured to talk to another core. In order to select the target core you have to inject appropriate initialisation scripts written in Seggers 'not quite sinmple c' scripting language. In order to change the scripts and ensure they have all run appropriately then you need to close down you connection to the target, set the new scripts and then reopen a connection to the new target core.
It is possible to adjust some details on the fly by executing some commands in a 'key=value' language but you can't do everything you might need to that way.
Recommended approach
What you can do is have multiple process sharing a JLink.
Each process initialised to a specific target core and then they share the JLink automatically on an API cal by API call basis. For compound, multiple api call, operations you need to serialise these operations using the dll API JLinkARM_Lock() and JLinkArm_Unlock() or you can potentially get processes 'jumping in' during these compound operations and having their behaviour become undefined or unreliable.
They to communicate with multiple target cores you do some inter process communication from your master process to your spawned JLink operation processes.
Remember to include keep alives in you inter process communication so that crashes or debugging doesn't result in a plethora of orphaned or silent processes.
I'm developing an application that is able to determine which application using internet. Now my problem is that i want to know the process name before it successfully establish connection much like a firewall.
I'm using Delphi2009. So the suggestions in that technology are appreciated.
Look at Winsock Layered Service Providers to monitor traffic. I believe LSPs are DLLs that get loaded into each process, so you should be able to call GetModuleFileName(NULL) to discover the EXE name when your DLL is loaded.
The Wikipedia article linked above shares my strongest concerns:
One major common issue with LSPs was that if they were to be removed
or unregistered improperly or if the LSP was buggy, it would result in
corruption of the Winsock catalog in the registry, and the entire
TCP/IP stack would break and the computer could no longer access the
network.
So if you are new to Windows programming and/or do not take proper precautions with writing these types of filter drives, then tread carefully. Otherwise, a bug in your program will easily screw up the user's machine.
I have a software architecture problem.
I have to design an IOS application which will communicate with a Linux application to get the state of a sensor, and to publish an actuator command. The two applications run in a Local network with an Ad-Hoc WiFi connection between the IOS device and the Linux computer.
So I have to synchronize two values between two applications (as described in figure 1). In a Linux/Linux system, I resolve this kind of problem thanks to any publisher / subscriber middleware. But how can I solve this problem in an IOS / Linux world ?
Actually the Linux application embed an asynchronous TCP Server, and the IOS application is an asynchronous TCP client. Both applications communicate through the TCP Socket. I think that this method is a low level method, and I would like to migrate the communication layer to a much higher level Service based communication framework.
After some bibliographic research I found three ways to resolve my problem :
The REST Way :
I can create a RESTful Web Service which modelize the sensor state, and which is able to send command to the actuator. An implementation of a RESTful web service client exists for IOS, that is "RESTKit", and I think I can use Apache/Axis2 on the server side.
The RPC Way :
I can create on my Linux computer a RPC service provider thanks to the libmaia. On the IOS side, I can use xmlrpc (https://github.com/eczarny/xmlrpc). My two programs will communicate thanks to the service described in the figure below.
The ZeroConf way :
I didn't get into detail of this methods, but I suppose I can use Bonjour on the IOS side, and AVAHI on the linux side. And then create custom service like in RPC on both side.
Discussion about these methods :
The REST way doesn't seem to be the good way because : "The REST interface is designed to be efficient for large-grain hypermedia data transfer" (from the Chapter 5 of the Fielding dissertation). My data are very fined grain data, because my command is just a float, and my sensor state too.
I think there is no big difference between the ZeroConf way and the RPC Way. ZeroConf provide "only" the service discovering mechanism, and I don't need this kind of mechanism because my application is a rigid application. Both sides knows which services exists.
So my question are :
Does XML RPC based method are the good choice to solve my problem of variable synchronization between an iPhone and a Computer ?
Does it exist other methods ?
I actually recommend you use "tcp socket + protobuf" for your application.
Socket is very efficient in pushing messages to your ios app and protobuf can save your time to deliver a message instead of character bytes. Your other high level proposal actually introduces more complications...
I can provide no answers; just some things to consider in no particular order.
I am also assuming that your model is that the iOS device polls the server to synchronize state.
It is probably best to stay away from directly using Berkeley sockets on the iOS device. iOS used to have issues with low level sockets not connecting after a period of inactivity. At the very least I would use NSStream or CFStream objects for transport or, if possible, I'd use NSURL, NSURLConnection, NSURLRequest. NSURLConnection's asynchronous data loading capability fits well with iOS' gui update loop.
I think you will have to implement some form of data definition language independent of your implementation method (RES, XML RPC, CORBA, roll your own, etc.)
The data you send and receive over the wire would probably be XML or JSON. If you use XML you would have to write your own XML document handler as iOS implements the NSXMLParser class but not the NSXMLDocument class. I would refer JSON as the JSON parser will return an NSArray or NSDictionary hierarchy of NSObjects containing the unserialized data.
I have worked on a GSOAP implementation that used CFStreams for transport. Each request and response was handled by a request specific class to create request specific objects. Each new request required a new class definition for the returned data. Interactivity was maintained by firing the requests through an NSOperationQueue. Lots of shim here. The primary advantage of this method was that the interface was defined in a wsdl schema (all requests, responses, and data structures were defined in one place.
I have not looked at CORBA on iOS - you would have to tie in C++ libraries to your code and change the transport to use CFStreams Again, lots of shim but the advantage of having the protocol defined in the idl file. Also you would have a single connection to the server instead of making and breaking TCP connections for each request.
My $.02
XML RPC and what you refer to as "RESTful Web Service" will both get the job done. If you can use JSON instead of XML as the payload format, that would simplify things somewhat on the iOS side.
Zeroconf (aka bonjour) can be used in combination with either approach. In your case it would allow the client to locate the server dynamically, as an alternative to hard-coding an URL or other address in the client. Zeroconf doesn't play any role in actual application-level data transfer.
You probably want to avoid having the linux app call the iOS app, since that will complicate the iOS app a lot, plus it will be hard on the battery.
You seem to have cherry picked some existing technologies and seem to be trying to make them fit the problem.
I would like to migrate the communication layer to a much higher level Service based communication framework
Why?
You should be seeking the method which meets your requirements in terms of available resources (should you assume that the client can maintain a consistent connection? how secure does it need to be?) However besides functionality, availability and security, the biggest concern should be how to implement this with the least amount of effort.
I'd be leaning towards the REST aproach because:
I do a lot of web development so that's where my skills lie
it has minimal dependencies
there is well supported code implementing the protocol stack at both ends
it's trivial to replace either end of the connection to test out the implementation
it's trivial to monitor the communications (if they're not encrypted) to test the implementaiton
adding encryption / authentication does not change the data exchange
Regards your citation, no HTTP is probably not the most sensible for SCADA - but then neither is iOS.
Problem
I am working on modifications to one of my applications that communicates with a telescope.
One of the most annoying problems due to nothing else but reckless poor design, is the GOTO controller and its keypad.
If anyone of you remember the Sinclair Spectrum you know what I mean. As well as the rubber keys, the crucial keys for guiding and slewing the telescope are awkward to locate when your eye is trying to adapt to the view.
All it takes is the wrong key and you spend another 30 minutes or so re-aligning the telescope.
Workaround
My solution is a game controller such as a wingman, it fits neatly into your hands and is easy to locate the buttons. Also there is no risk of reseting the mount.
Question
My question is this, how does Delphi interact with game controllers because tthere is no mention in the documentation? Otherwise how do I access a gameport when it is connected through a USB dongle?
Working with the game controller is part of the Windows API. JEDI's JVCL has a Human Interface Device (HID) constroller (TJvHIDDeviceController) component that does what you want.
Delphi applications running on "NT" line operating systems (NT, 2000, XP, Vista, 7, 2003, 2008...) can't access hardware devices directly. Only drivers can, because the I/O ports required to access them can be accessed only by code running at the right IOPL level (which is 0 in Windows). There are some generic drivers available that open any I/O port (thus creating a security hole) that user code can call.
But tt's far better to rely on device drivers, and use the HID API to interact with them. Windows will recognize most older devices (like the serial/game port Wingman), while newer USB ones or use the standard drivers that come with Windows, or come with their own. Once the system recognizes the devices, you can use them in a standard way with no need to dig in the low-level details.
We intend to design a system with three "tiers".
HQ, with a single server
lots of "nodes" on a regional basis
users, with iPads.
HQ communicates 2-way with the nodes which communciate 2-way with the users. Users never communicate with HQ nor vice-versa.
The powers that be decree a Windows app from HQ (using Delphi) and a native desktop app for the users' iPads. They have no opinion on the nodes.
If there are compelling technical arguments, I might be able to beat them down from "decree" to "prefer" on the Windows program (and, for isntance, make it browser based). The nodes have no GUI, they just sit there playing middle-man.
What's the best way for these things to communicate (SOAP/HTTP/AJAX/jQuery/home-brewed-protocol-on-top-of-TCP/something-else?) Is it best to use the same protocol end to end, or different protocols for hq<-->node and node<-->iPad?
Both ends of each of those two interfaces might wish to initiate a transaction (which I can easily do if I roll my own protocol), so should I use push/pull/long-poll or what?
I hope that this description makes sense. Please ask questions if it does not. Thanks.
Update:
File size is typcially below 1MB with nothing likely to be above 10MB or even 5MB. No second file will be sent before a first file is acknowledged.
Files flow "downhill" from HQ to node to iPad. Files will never flow "uphill", but there will be some small packets of data (in addition to acks) which are initiated by user action on the iPad. These will go to the local node and then to the HQ. We are probably talking <128 bytes.
I suppose there will also be general control & maintenance traffic at a low rate, in all directions.
For push / pull (publish / subscribe or peer to peer communication), cross-platform message brokers could be used. I am not sure if there are (iOS) client libraries for Microsoft Message Queue (MSMQ), but I would also evaluate open source solutions like HornetQ, Apache ActiveMQ, Apollo, OpenMQ, Apache QPid or RabbitMQ.
All these solutions provide a reliable foundation for distributed messaging, like failover, clustering, persistence, with high performance and many clients attached. On this infrastructure message with any content type (JSON, binary, plain text) can be exchanged, and on top messages can contain routing and priority information. They also support transacted messaging.
There are Delphi and Free Pascal client libraries available for many enterprise quality open source messaging products. (I am am the author of some of them, supporting ActiveMQ, Apollo, HornetQ, OpenMQ and RabbitMQ)
Check out MessagePack: http://msgpack.org/
Also, here's more RPC discussion on SO:
RPC frameworks available?
MessagePack: fast cross-platform serializer and RPC - please share experience
ICE might be of interest to you: http://zeroc.com/index.html
They have an iOS layer: http://zeroc.com/icetouch/index.html
IMHO there are too little requisites to decide what technology to use. What data are exchanged, how often, what size? Are there request/response time constraints? etc. etc. Never start selecting a technology before you understand your needs deeply.