Best approach to program a PLC using dbc file? (CAN communication) - can-bus

This is probably not the right forum to ask this, but I need to program a Phoenix Contact PLC in Structured Text. The PLC should communicate with a motor that uses CANOpen protocol. The only resource I have is the dbc file. I'm kinda lost about where to start. If you have some suggestions/recommendations I would appreciate it.

Implementing a CANopen stack can be very time consuming and complex but make a node working with your soft can be easy depending on the slave you have to control.
A good tip would be first to connect the motor to CAN viewer like PCAN View or whatever depending on hardware you have.
First step is to send the start message at adress 0x000 DLC:2, Data 01 00 to start all slave or 01 motor node id to start only the motor.
This will force the motor to start in operational mode and you will be able to see if it send something or not.
You should probably see a heartbeat message with ID: 700+node id and maybe some PDO with a the current speed, temperature or whatever (the motor documentation should help you better understand what the motor send and wait).
In this case in your soft you would have to implement the start message sending if no heartbeat or heartbeat value different than 0x05 (means operational), the PDO read if there is one and a PDO control command which give to the motor the speed needed (you should find the message in the motor documentation)
There might be some other needs like SDO parametrization but worth to try with these few steps before
Please let me know I can help you

Related

Is there any way to stop a particular CAN message coming from an external device on the bus in CANoe?

I am looking to test a scenario, how my software will respond to disconnection of a particular CAN message coming from an external device. This external device will send many CAN messages in the bus, so I cannot control it to stop just a particular message.
Therefore, I am looking for a way in CANoe just to stop one particular CAN message coming into the bus.
Please need your suggestions here.
I tried to provide as much information here, if more is require kindly put in the comment. Thanks.
You would have to split the bus into two and configure CANoe to act as a gateway:
You need a network interface with two CAN channels.
You connect your DUT to one channel (say CAN2) and the remaining bus to the other channel (CAN1).
You then configure both busses in CANoe and add a node to both busses in the simulation setup.
This node should listen to all messages received on CAN1 and output them to CAN2 and vice versa.
If you want certain messages not to reach CAN2, you have to adapt the logic of this node.
Refer to this article in the Vector knowlegde base on how to setup a gateway between two CAN busses and how to control the message flow between those busses.

Frame acknowledgement in CAN bus

How does the sender on the CAN bus know that a node has not properly received the data?
I am currently learning the functioning of the CAN bus. Based on what I have seen so far a receiver drives the bus to a dominant state when it successfully obtains a packet and one receiving node is enough to accomplish this. However, in the event where the intended receiver does not successfully obtain the packet while others do, how is the sender made aware of the situation so that it can retransmit the packet?
Any help in providing some clarity on this topic is much appreciated. Thank you.
The sender can't know this unless you implement a higher layer protocol. The ACK slot in raw CAN frame allows sender to detect if it (not the receiver) has a bus problem. If the sender doesn't sample an ACK, it can conclude that "No one is hearing me in the bus. Maybe I'm physically disconnected or something is completely wrong."
For example in CANopen, it's generally receivers job to complain if an expected PDO packet doesn't arrive on time. Although it's not correct to talk about masters and slaves in CAN bus, a device you assign a master role can be programmed to expect periodic PDO report packets from its slaves, and can rise an error flag if they don't arrive in expected time window.

Semantics of an HL7 enabled Point of Care device - is this the right way to do it?

I am implementing automated HL7v2.7 reporting of observations on a point of care device. The way this works is by sending an "ORU^R30 Unsolicited Point-Of-Care Observation Message without Existing Order - Place an Order" message to what I'm assuming will be a laboratory information system or an associated channel in an integration engine. I'm currently going to have the device ask for IP/port numbers to the LIS and MPI/their associated connections on first set-up - our device is going to communicate over TCP/LLP.
Is this the smart way to do all this? I've never worked with HL7 or any kind of HIS before.
I appreciate any possible insight. This isn't the stuff you can learn about in the standard, and I don't think I can just email Epic and ask them how they design EHR/HIS systems.
Thanks!
Message Content: ORU^R30 is not a commonly used message type, but the structure is close enough to R01 that most systems will be able to receive it. Focus on making sure you collect as much patient demographics and the visit number, or better yet scan both from the patient's wristband barcode. You must have patient and visit to file the observations.
Transmission: It's safest to just do MLLP over TCP, it will speed up your installs because that's what everybody else does. The alternative is having the health system write something custom to receive the data, usually via the interface engine.
Network: It sounds like you're thinking of putting the connection info on the device. This probably is a bad idea, I would build some kind of aggregator service that actually sends data to the EHR, that way you don't have to deal with multiple devices trying to get through firewalls, etc.

How do I increase the priority of a TCP packet in Delphi?

I have a server application that receives some special TCP packet from a client and needs to react to it as soon as possible by sending an high-level ACK to the client (the TCP ACK won't suite my needs).
However, this server is really network intensive and sometimes the packet will take too long to be sent (like 200ms in a local network, when a simple server application can send it in less than 1ms).
Is there a way to mark this packet with a high-priority tag or something like that in Delphi? Or maybe with the Win32 API?
Thanks in advance.
EDIT
Thanks for all the answers so far. I'll add some details. My product has the following setup: there are several devices that are built upon vehicles with WIFI conectivity. When they arrive at the garage, those device connect to my server and start to transmit data.
Because of hardware limitations, I implemented a high-level ACK to make the device aware that the last packet arrived successfully (please, don't argue about this - the data may be broken even if I got a correct TCP ACK). However, if I use my server software, that communicates with a remote database, to issue this ACK, I get very long delay (>200ms). If I use an exclusive software to do this task, I get small latencies (<1ms). So, I was imagining if I could just tell Windows to send those special packets first, as it seems to me that this package is getting delayed so the database ones can get delivered.
That's the motivation behind my question.
EDIT 2
As requested: this is legacy software and I'm using the legacy dclsockets140.bpl package and Delphi 2010 (14.0.3593.25826).
IMO it is very difficult to realize this. there are a lot of equipment and software involved. first of all, if you communicate between 2 different OS's you got a latency. second, soft and hard firewalls, antiviruses, everything is filtering/delaying your package.
you can try also to 'hack' the system(this involve some very good knowledge on how the frames/segments are packed/send,flow control,congestion,etc), either by altering it from code, either by using some tools like http://half-open.com/ or others.
In short, passing MSG_OOB flag to the send function marks the data as "urgent". Detailed discussion about the OOB in the context of Windows Sockets implementation specifics is available here.

easy to write a script to test whether the network is ever down for the next 24 hours?

is it easy to write a script to test whether the network is ever down for the next 24 or 48 hours? I can use ssh to connect to a shell and come back 48 hours later to see if it is still connected to see if the network has ever been down, but can i do it programmatically easily?
The Internet (and your ethernet) is a packet-switched network, which makes the definition of 'down' difficult.
Some things are obvious; for example, if your ethernet card doesn't report a link, then it's down (unless you have redundant connections). But having a link doesn't mean its up.
The basic, 100 mile view of how the Internet works is that your computer splits the data it wants to send into ~1500-byte segments called packets. It then, pretty much blindly, sends them on their way, however your routing table says to. Then that machine repeats the process. Eventually, through many repetitions, it reaches the remote host.
So, you may be tempted to define up as the packet reached its destination. But, what happens if the packet gets corrupted, e.g., due to faulty hardware or interference? The next router will just discard it. Ok, that's fine, you may well want to consider that down. What if a router on the path is too busy, or the link it needs to be sent on is full? The packet will be dropped. You probably don't want to count that as down.
Packets routinely get lost; higher-level protocols (e.g., TCP) deal with it and retransmit the packet. In fact, TCP uses the packet drop on link full behavior to discover the link bandwidth.
You can monitor packet loss with a tool like ping, as the other answer states.
If your need is more adminstrative in nature, and using existing software is an option, you could try something like monit:
http://mmonit.com/monit/
Wikipedia has a list of similar software:
http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
You should consider also whether very short outages need to be detected. Obviously, a periodic reachability test cannot guarantee detecting outages shorter than the testing interval.
If you only care about whether there was an outage, not how many there were or how long they lasted, you should be able to automate your existing ssh technique using expect pretty easily.
http://expect.nist.gov/
Most platforms support a ping command that can be used to find out if a network path exists to an IP address somewhere "else". Where, exactly, to check depends on what you are really trying to answer.
If the goal is to discover the reliability of your first hop to your ISP's network, then pinging a router or their DNS regularly might be sufficient.
If your concern is really the connection to a single node (your mention of leaving an ssh session open implies this) then just pinging that node is probably the best idea. The ping command will usually fail in a way that a script can test if the connection times out.
Regardless, it is probably a good idea to check at a rate no faster than once a minute, and slower than that is probably sufficient.

Resources