I have recently come across Adaptive AutoSAR, I see all the Domain Controller/ECUs on the Adaptive side uses Ethernet Switch port to connect to other ECUs or Gateways. I know Switch has many features, but Could you please explain
1. Can we use inbuilt Ethernet Ports for doing the same functionality. or
2. What can the Switch provide which Ethernet Port doesn't.
Unlike CAN and other communication interfaces, SOC could not direct connect by Ethernet port interfaces. A second-layer switch should be used to be divided the network into different collision domains.
Related
I still have the fischertechnik computing interface 30566.
Is it possible to steer this interface via a modern USB port (instead of the C64 userport)?
I know there are adapters for turning USB into 5V TTL. Or do I need to have RS-232 in between?
And then?
For a week I've played with cheap modbus RS485/Ethernet adapters like USR-TCP232-304. I was assuming they would "speak" modbus TCP on the ethernet side and modbus RTU over RS485. After countless experiments I've found what that these adapters are actually expecting is RTU over TCP on the ethernet side, so they're not repackaging the ADU/PDU but simply relay.
Is this a standardized way of doing modbus or do I simply misunderstand what's going on?
Looking at the datasheet for the USR-TCP232-304 I see no mention of Modbus support; it's a RS485 Serial to Ethernet Converter only. These units makes no attempt to understand the data flowing over the link (if they receive a byte via RS485 they send it via the TCP link and vice versa). They can be used to talk to pretty much any device that uses RS485 (there are a lot of other protocols that run over RS485).
Modbus RTU transmitted via this kind of unit is pretty common if not exactly standardised (it's not mentioned in the modbus spec to my knowledge). Often these devices include drivers that present themselves as a serial port so, from the applications perspective, there is no real difference between direct RS485 and going via one of these devices (other than timings).
It looks like the next model up includes a modbus gateway function that will act as a Modbus TCP server (and there are plenty of other options; they generally cost a bit more because of the additional processing required).
I'm trying to host a wifi from either a lan connection (if available) or either sharing a network.
I did use the tutorial : https://kaiuwe.hüber.de/raspberry-pi-wifi-repeater-ohne-adapter/
But this just acts as a repeater ...
My expectation is a possibility to share wifi over wlan or when a lan connection is active share the wifi from lan.
I'm not sure you know enough about WiFi or TCP/IP networking to ask your question sensibly. What do you mean by "share WiFi?" There are two common scenarios:
Your Pi works as a WiFi bridge to an Ethernet LAN. In this case, the WiFi and the LAN are the "same" network, just different media. For instance, if your LAN uses the IPv4 address 192.168.42.0-255, your WiFi users will also share this network.
Your Pi works as a WiFi router, with an Ethernet LAN as the "uplink." In this case, your WiFi network has its own range of addresses, probably managed by your Pi, and the Pi works as a router between the WLAN and the LAN. This is like what most home WiFi access points do. (You will probably need to have the Pi do Network Address Translation as well. For some reason, Linux people insist on calling this 'masquerading.')
If you can clarify which of those you want to do, I could provide some pointers going forward. You many want to do some reading on the basics of TCP/IP networking first. If you don't know how a bridge and a router differ, you won't be able to ask useful questions.
I try to connect an Omron PLC (CP1L) to a PC through an Ethernet Option Board. I have setup connection correctly and is able to connect to the PLC to configure its IP and various settings.
Then I have problem getting the ladder program to run correctly.
Documentation indicates address A202.00 will turn on when communication is enabled, but when I simulate the ladder program, the address A202.00 always turn ON. Even when I disconnect the Ethernet cable, the address remain turn ON. I do not understand why the address remain turned on even there is not ethernet cable connecting the PLC and the PC.
Simulated ladder program indicates A202.00 always turn ON:
If you have the physical PLC then why are you running in simulation? If you want to debug the real system just plug into it with a USB cable and use "PLC -> Work Online...". I don't think networking simulates exactly right since the simulator itself uses simulated networking to work. In any case, if you are running in simulation then the state of the real ethernet port on the real PLC will have absolutely no impact on the simulation. It doesn't care that you even have a real PLC at all.
In any case A202.00 is just a "Port not busy" flag. You use it to guard rungs against trying to read/write from the same port at the same time or to trying to perform multiple simultaneous reads or writes. A202.00 is ON so long as the com port is not busy. If it is reading or writing then the A202.00 will go OFF for the duration of the read or write, preventing other communication rungs guarded with it from executing, and then returns to the ON state.
I am building an Arduino based servo driver that I want to control with OSC commands from my iPad over the Internet.
Is it possible to send OSC commands over 3G / UMTS with my iPad or iPhone to control a device? So I will not be limited by the router's range when I send OSC commands to the controller when both devices are part of the same Wi-Fi network.
It seems that the applications I downloaded (TouchOSC, iOSC) can only send OSC data over Wi-Fi, however I'd like to send the commands over the Internet (with port forwarding settings in my router).
I would get one of these. Look ma, no wi-fi :)
OSC typically uses UDP (User Datagram Protocol), even if some newer OSC implementations also allow TCP/IP messaging (also see Difference between TCP and UDP?).
Unfortunately (as far as I know), UDP does not work over 3G, which seems to be your problem. In other words: two mobile devices cannot talk to each other on a cellular network. So it has nothing to do with OSC apps not being able to do this, it's just not available from the cellular network.
However (I think, not tested), I see two workarounds here:
try to use TCP/IP instead of UDP to send your OSC packets
if you need UDP on the Arduino side, you could use a server in-between
Do port forwarding on your router to forward port x to the Arduino, and then use the IP address from whatsmyip.com and use that one in the touchOSC app when inputting the IP address. That may work.