I am new with CANoe, and now I am trying to test a real ECU by sending diagnostic requests to it and get response from the ECU via CANoe. I use VN5610A and CANoe software is CANoe.Ethernet. I connected the VN5610A to PC and the ECU. I configured the Diagnostics/ISO TP configuration by uploading a ODX file as database. Then when i start logging, I can see the ethernet package infomation in the trace window. And if i send request via other external tools, i can also see the communication in the trace window. But how can i send request via Caone?
I now have some questions firstly:
I want to test a real ECU, should I use the simulation setup? I mean should i need to simulate the real ECU as a simuLated ECU? If not, I would not use Diagnostics Console to send request. Actually I tried to setup the simulated ECU and send request via Diagnostics Console. But the real ECU did not really received the request, just the simuated ECU received.
in the Vector Hardware Config, we can define VN5610A's IP address, should this IP address the same as my PC IP address? If not the same? which IP address should be assigned to "Tester Present"?
If config below in the Vector Hardware Config correct? Should PC and CANoe be the same virtual Port?
Thanks a lot in advance.
if you want to simulate real ECUs, the best way normally is to generate a rest bus simulation for the whole bus using the respective signal data bases and then comment out the ECU you need and connect it to the interface, instead. ECUs that are deactivated in the simulation setup are not simulated and thus can be set to the real bus. When the ECU is activated, you should also see the connection change in the simulation setup to the other wire. If you do not deactivate the ECU, CANoe will simulate it for you.
Maybe you can also have a look at the Examples. If you have not installed them together with CANoe, I recommend doing so. They're actually quite good :-)
Related
I have some data aquisition devices in industrial machinery that have 4G connectivity. Right now I make them to stream the intrumentation data in real time to my server through raw TCP/IP protocol. But this has some problems:
The machinery sometimes work in places where there is low or null mobile connectivity. If there is no connectivity for too long it can happen two things: a) the machine gets shutted down and the tcp/ip buffer it's lost along with the instrumentation data or b) the tcp/ip buffer overflows, which has the same results.
The same as point 1, but for the server side, due to maintenance or if something in the server fails in the weekend when nobody is going to notice it but the machinery can be ON and working. Then we can have data loss in the same way as point 1.
I have to manage authentication and the connection of all the clients into a server single TCP port. I have done some temporary hack that works for the moment but isn't the best. But this is another problem and it's not the reason of this question, so take it only for context.
So, I should code an application layer acknowledge where the server tells the client when a high-level message (not the individual TCP packets) has been received and processed. And in the client side to have a buffer writted in-disk where data is being deleted as is being confirmed by the server. This, to solve points 1 & 2.
But I'm afraid that I'm reinventing the wheel or that I don't know the correct tools, because I think that this problem should be more or less common but I fail to google for it and I can't find a library or tool that does this job.
What I was thinking about is something that in the remote client is listenning in a local TCP port for incomming data from the DAQ software, once it receives a message it streams it to the server and writes it to the local disk. In the server, the tool receives the message and re-streams it over local network to the final server. Then, notifies the client that is able to delete the message from its disk buffer.
So, the question is, there is something already done? I would prefer an already compiled / language agnostic solution because I code in LabView and I know there isn't like that in its ecosystem, but I'm open to everything. If there isn't anything like that, any advice in what to do / to avoid when developing it myself?
Thanks for your time.
I am having the data in Modbus TCP/IP. I have to read the available data with Apache NiFi. I don't know, which processor have to use exactly (Ex. GetTCP, ListenTCP, Plc4xSourceProcessor). Can you help me on this? Is there any feasibility with Apache NiFi?
the Plc4xSourceProcessor is what you are looking for. The Apache PLC4X project provides drivers for accessling PLCs using various protocols. One of the is the Modbus protocol. So if you use the Plc4xSourceProcessor and configure a modbus connection string and list the addresses you want to collect, then you will be able to do so.
I happen to have written the PLC4X-NiFi Integration documentation on our website just a couple of days ago: https://plc4x.apache.org/users/integrations/apache-nifi.html
I think this will be helpful.
Chris
I don't really know what Modbus TCP/IP is, but it basically comes down to whether you want NiFi to be a client or a server.
ListenTCP creates a TCP server that is waiting for some client to make a connection and start sending data. The most common case would be a log forwarding system like syslog which can be configured to forward logs to a host/port over TCP.
GetTCP is a client that connects to some host/port which is the server, and starts reading data.
Plc4xSourceProcessor is not part of the official Apache NiFi code, but from quickly looking at it, it seems like more of a client processor similar to GetTCP since you give it a connection string telling it where to connect to.
I bought a Simcom (Sim7080G) module to use it for geolocation and send data over TCP. These modules are quite new on the market (it was first launched in mid 2019) and there is some weird functionning with it. I would like to know if people that use it struggle with the same problem.
My goal is to take GNSS (latitude/longitude) informations, and to send them over TCP.
Activate and take GNSS informations
AT+CGNSPWR=1
returns OK
AT+CGNSINF returns +CGNSINF: 1,1,20200517191239.000,4x.xxxxxx,6.xxxxxx,473.769,0.00,,0,,1.9,2.1,1.0,,7,,7.9,6.0
Connect to any TCP server
AT+CNACT=0,1 returns OK\r\n\r\n+APP PDP: 0,ACTIVE
AT+CAOPEN=0,0,"TCP",151.101.1.69,80 (151.101.1.69 is stackoverflow.com ip address)
--> Some time waiting (like +40s) and then:
+CAOPEN: 0,23\r\n\r\nOK
The code 23 means: 23 Remote refuse, but in my case the connection never reached the server.
Only GNSS or TCP can be used, but not both
What is weird about all of this, is the fact that I can connect on a TCP server, but this stops to work when I activate GNSS.
I sent an email to Simcom technical support.
After insisting that my problem be addressed by a Simcom engineer, I received an answer. I encouraged them to be more clear on their documentation because this information was nowhere (this module is pretty new so I think they missed it on documentation).
Hope to help somebody in the same way or not to do the same pricey error:
Hi Dardan,
"it is not possible to use GNSS and TCP at the same time"
This is known limitation for this module, as there are limitation for
LTE and GNSS part, they can not run simultaneously because they are
sharing part of RF components(SIM7070G low cost version of SIM7000G)
so it is time MUX for LTE and GNSS which means the GNSS performance
could not be good(if customer needs to send GNSS data to server in
very short interval such as <10 seconds), for SIM7000G LTE and GNSS
can work simultaneously without problem. so SIM7070G could be a good
solution for "parcel tracking" etc, which do not need the continue
navigation. please go for SIM7000G, thanks.
xxxx Sun
I found this issue some hours before read this post. My product publishs in AWS IoT MQTT broker; it works, but I need the GPS coordinates to be sent together in message. I'm a lot frustrated, because such problem should be said in Simcom's documents. My previous version was using sim7600g, more expensive, but works fine. I live in Brazil, everytime I need to test some different module I loose more than 1 month to buy from China or somewhere and arrive a new one to me. I tried to turn ON/OFF GNSS and the TCP conection in alternate way, but is too slow the process to reconnect on gsm network.
Ran into this as well. With MQTT it is possible to power down the GPS unit to be able to send and receive MQTT messages without reconnecting/subscribing to the broker again. I've made a 30 second interval to enable/disable the GPS unit and tested it with HiveMQ public broker. Receiving of position data every 60 seconds is possible with this setup, which might be sufficient for some applications. For the price, it has this is still a good module.
I receive no response for HTTP Get request for the http://httpbin.org/get URL. Following is the output using the AT Command Tester from https://m2msupport.net
Checking registration status...
AT+CREG?
+CREG: 2,1,"912","3D73",0
OK
The device is registered in home network.
AT+CGREG?
+CGREG: 2,1,"912","3D73",0,"1"
OK
The device is registered in home network.
Device is registered..
Check the network APN...
AT+CGNAPN
+CGNAPN: 0,""
OK
Network did not send APN to the device.
Activate the network bearer...
AT+CNACT=0,1
OK
+APP PDP: 0,ACTIVE
Set up the HTTP URL...
AT+SHCONF="URL","httpbin.org"
OK
Set up the HTTP body length...
AT+SHCONF="BODYLEN",1024
OK
Set up the HTTP header length...
AT+SHCONF="HEADERLEN",350
OK
Initiating HTTP connection...
AT+SHCONN
OK
Get the HTTP connection state...
AT+SHSTATE?
+SHSTATE: 1
OK
HTTP connection is successful...
HTTP get request...
AT+SHREQ="http://httpbin.org/get",1
OK
No reponse received..
I have been writing my own version of the 802.11 protocol with network stack. This is mostly a learning experience to see more in depth on how networks work.
My question is, is there a standard for replying to client devices that a certain protocol is unsupported?
I have an android device connecting to my custom wifi device and immediately sending a TON of requests at the DNS port of my UDP protocol. Since I would like to test out other protocols I would very much like a way for my wifi device to tell the android device that DNS is not available and get it to quite down a little.
Thanks in advance!
I don't see a possibility to send a reply that a service is not available.
I can't find anything about this case in the UDP specification.
One part of the DNS specification assumes that there are multiple DNS servers and defines how to handle communication with them. This explains part of the behavior in your network, but does not provide much information how to handle it.
4.2.1 Messages - format - UDP usage
The optimal UDP retransmission policy will vary with performance of the
Internet and the needs of the client, but the following are recommended:
The client should try other servers and server addresses
before repeating a query to a specific address of a server.
The retransmission interval should be based on prior
statistics if possible. Too aggressive retransmission can
easily slow responses for the community at large. Depending
on how well connected the client is to its expected servers,
the minimum retransmission interval should be 2-5 seconds.
7.2 Resolver Implementation - sending the queries
If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address.
According to this you could try to send garbage back to the client, but this is rather a hack, or an error, but how does an error look like? Such a solution assumes that you have knowledge about the service that you don't support.
I believe that the DNS - requests can be avoided by using DHCP. DHCP allows to specify DNS-servers as listed in the linked page. This is the usual way that I know for a DNS-resolver in a LAN to get initial DNS servers although I don't find anything about this in the DNS specification. You can give the Android - device a DNS-server with DHCP so that it does to need to try to query your device. Querying your device could be a fallback.
Additionally to DNS there is mDNS which uses multicasts in the network to send queries. This seems not to be the protocol you have to do with because it uses the special port 5353.
Not possible to stop DNS in the way you intend. However, only for your tests you can check the UDP messages and find out the names the device is looking for. Then you update the hosts file (google how to do it: http://www.howtogeek.com/140576/how-to-edit-the-hosts-file-on-android-and-block-web-sites/) and add those names with some localoop IP address. That might work for your test.
Other possibility is to change DNS server to some localloop IP address: http://xslab.com/2013/08/how-to-change-dns-settings-on-android/
Again, this is only to avoid having all the DNS messages through the wifi connection.
Unfortunately I don't know much networks. I am writing a program that has two versions. A server version and a client version. Lets assume that the client versions are installed on, say 20 PCs that are connected to the server over ethernet. The client versions needs to CONSTANTLY get some data from the server. The data is kind of serial. I wanted to know a way to broadcast the data that gets updated every second and make it available to all the other PCs in the network. Could I use the HTTP Port for this?, like writing the data to an HTML page or something? or Is there a better port or method for doing this?
Any ideas will be greatly appreciated.
This sounds like a pretty straightforward application of TCP sockets. The server would be set up to "listen" on a particular port (you pick the port number, say 12345), and each client would make a TCP connection to the server on that port.
Whenever the server has data to send, it would send it once to each connected client. This could mean that the server sends the data up to 20 times on different sockets, but that's fine. The client would read the data from its connected socket to the server.
There are other alternatives, such as UDP or even UDP multicast, but these usually end up being a lot more complicated because UDP doesn't guarantee that packets always arrive at the destination (and they may even be duplicated or out of order). TCP ensures that the data you send either arrives complete in the correct order, or doesn't arrive at all (in that case the connection would be dropped).
An example of this sort of multiple TCP connection is VNC:
VNC is widely used in educational contexts, for example to allow a distributed group of students simultaneously to view a computer screen being manipulated by an instructor, or to allow the instructor to take control of the students' computers to provide assistance.
There are many ways. you can choose any of them but i think, document below will help you a lot.
Multicast over TCP/IP HOWTO:
http://www.ibiblio.org/pub/Linux/docs/howto/other-formats/html_single/Multicast-HOWTO.html#sect-trans-prots