I have modbus touch panel with 4 buttons which is connected to a modbus relay board via rs485(A and B).
I want to program the touch panel so when i click a button to open a specific relay in relay board.
As i see from the touch panel manual and his registets every button has 0 or 1 value.
My question is what i need to do?? Should i write to touch panel registers or write to modbus relay?? How can i take the command that is coming from the panel and day to relay to open? I am a little confused withbthe process i need to follow.
First of all you have to know that Modbus communication works in a Master/Slave perspective, in which only master can send requests, slave will only reply to those requests.
So touch panel have to be the master in communication, the relay board will be slave.
Then, Modbus identifies every 16bit parameter with a Register Address; a list of addresses make a Modbus Map.
To correctly send request to the relay board, you have to know the modbus map of the relay board:
(for example)
Register: Relay 1 command, Address: 0
Register: Relay 2 command, Address: 1
Register: Relay 3 command, Address: 2
etc...
Register: Relay 1 status, Address: 10
Register: Relay 2 status, Address: 11
etc...
The task you have to accomplish is to make your touch panel send a write request to the relay board; the request will be to write a "1" in the register linked to relay.
Commercial touch panels often have wizards and the implementation shouldn't be too much specific
Related
I have message in kernel space and want to give this message to snmp agent (a user space program communicate via Ethernet)(net-snmp).
How can I give a message from kernel space to snmp agent?
a)find a receive call in snmp agent (socket receive function) and receive the message via Ethernet driver by using socket communication. it is possible or right way to do ?
b)send message to user space via raw socket communication applied in the driver. is it possible? because when using some function like socket in kernel it angry with me, is there alternative way and sensible.
c)send message to user space and in user space use socket communication send the message via loop-back to snmp agent?
d)none of them, is there brilliant way :?
Which one is right how can overcome this issue? Thanks for your consideration and time.
I am trying to send data from a Northbound application that I have written, into the Ryu application.
The NB app is performing a lot of computation, so I have chosen to run it outside of Ryu. How do I send this information into the Ryu controller so the controller can act on it.
This set up would look like this:
[Northbound packet sender with actionable information (not in the SDN dataplane!!)]
↓
[Ethernet 1 (if on a different machine), or the Linux localhost (if on the same machine)]
↓
[Ryu Machine]
↓
[Ethernet 2 (using OpenFlow)]
↓
[Data plane]
In Pox I have simply set up a thread that can receive packets on a port. When it receives a packet it just creates an event, and my main SDN app can then use this event to perform the network changes needed. When I try this approach in Ryu, it just doesn't work. It seems that when I try to register a socket inside a Ryu app, Ryu will not run until that functionality has been removed.
Any advice?
Thanks in advance,
I’m really new on the coding world and I need your help. I need to do the following:
In a Zedboard platform I take data from a USB port and want to make real time packets and send them via TCP.
I have establish FreeRTOS for that. I take the data from a UART and keep them in a cycle buffer. I send a TCP command from Matlab for starting the transmission but that gives me just one packet of data. How a make this real time?
I'm afraid I don't understand your question - you mention both USB and UART - is the USB a virtual COM port? Whether its a UART of a USB port, once the received data is placed in the buffer you can use something like a direct to task notification to unblock a higher priority task to then send that data over the TCP link.
There is a FreeRTOS/Zynq/TCP example on the following link: http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCPIP_FAT_Examples_Xilinx_Zynq.html
I'm in the process of making a multiplayer game, where the players' movements are sent over the network and their positions are stored in the server. I've been told that UDP would be best since it doesn't rely on constant connection and it won't matter if the client misses a packet. The clients could be on any router, not necessarily within the server's LAN.
Is it possible to set up a server that the clients can connect to that will send all of them periodic updates of the positions of nearby objects/players?
I don't want to have to send packets to each individual client, and I heard multicasting can solve this problem, but every example I've seen only sends packets over a local network. Can I multicast past routers, and if so, how can I do that in Java? (And explain it to me like I have no idea what I'm doing, which is mostly true)
Ex.
Server has IP address 71.10.200.133
Client A has IP address 38.49.339.293
Client B has IP address 37.28.487.388
...
Client Z has IP address 43.38.382.949
Client A sends an update about the player's position to Server
Server sends update to B-Z without iterating a packet to each individual client. How do I accomplish this (if it's possible)?
Multicasts will traverse a router if and only if the router allows it. Unless you're in control of all the routers between you and your clients, the answer to your question is 'no'.
Multicast packets are broadcasts, thus they reach each node on that subnet. For you to send a multicast packet out on the web is not an effecient nor smart way of sending data.
For LAN based traffic:
Multicast is fine
But, for internet traffic I would suggest making a:
UDPClient
or
TCPClient
for internet based traffic and possibly multicast for LAN based (to mix things up a bit).
For internet traffic: Keep in mind, clients will need to initiate the connection first since most routers (household) have a firewall blocking all NEW outside-to-in traffic. So create a socket to listen over a designated port/ports for any incoming connections and from there on use which ever method of packet broadcasting/sending you like
You do also have the option of using Multicast proxies or Layer 2 VPNs if you have the capabilities. L2TP, https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol
A layer 2 VPN would relay unicast and multicast packets.
That would basically allow you to control the routers as EJP suggested above.
This questions also 3 year old so you've probably already figured a way to do it by now.
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.