Apologies if this subject has been covered but I cannot find a close enough answer.
I want to control a machine from a PC, using serial. I dont know if a Photon is the right thing to use.
Currently we use an interface at the pc, which converts serial to current loop. The current loop connects via cables(up to 100m), to the machine. What I want to do is convert this to wireless(Wifi). Would it be possible and practical, to communicate via wifi to a Photon at the machine, then from the Photon, convert to current loop which will connect to the machine.
Unfortunately I dont have access to the machine firmware and cannot change it. Can I communicate from the PC to Photon via TCP/UDP and then convert to current loop for the machine. Also being in mind I dont
want to go via the internet, but directly to the Photon from the PC via wifi.
PC ------> (Wifi) Photon —> Serial -> Current Loop —> Machine
Ultimately you would like to have many Machines connected to a single PC through multiple photons
PC -----> (Over Wi-Fi) Photon-1 ----> Serial -> Current Loop --> Machine-1
------> (Over Wi-Fi) Photon-2 —> Serial --> Current Loop —> Machine-2
…
------> (Over Wi-Fi) Photon-n —> Serial --> Current Loop —> Machine-n
To your question #2, each Photon has a unique device ID and access token. You can connect to the Photon using TCP/UDP. Using TCP/UDP will be local as @kennethlimcp mentioned. You can also use Particles REST APIs to send information to Photon, but this goes over the cloud. Please check http://docs.particle.io/core/api/
<<PC -----> (Over Wi-Fi) Photon-1 ----> Serial -> Current Loop --> Machine-1
------> (Over Wi-Fi) Photon-2 —> Serial --> Current Loop —> Machine-2
…
------> (Over Wi-Fi) Photon-n —> Serial --> Current Loop —> Machine-n>>
Yes this is exactly what I would like to do, but before I start the project, is the Photon the way to go?
Is the Photon my best option for this project?
If so, I will have to order a Photon, hope i can get stock. I only have a spark currently.
I would like to start with the first step. Are there any libraries/code samples available for Photon
for the “PC----->(over wifi and using TCP) Photon-n to serial” step?
Yes, I was considering that. Would it make the project simpler?
The only problem I have with that is, in the future I would like to use a tablet instead of the pc and there is one problem with this. You only have one usb(otg) port on most tablets and this port is also used for charging. I cannot find a solution that allows me the charge and communicate from the same otg port.
Hope you have taken into account porting of the PC code into the tablet environment. Porting challenges will depend on the language used on the PC and the Tablet OS considerations(android or Windows OS)
There are USB-Serial converters availablehe for mobile/tablet platforms. You can see a demonstration of USB-Serial converter use with Android at https://www.youtube.com/watch?v=vY8nviGw49E&hd=1
Do you have any constraints to use the PC code on the tablets?
There usb to serial in not the problem. The problem is when the usb to serial is plugged into the tablet, the tablet does not charge. This is fine if you are doing some communication and then disconnecting, but I want the tablet to monitor the machines permanently 24/7.
@fletch, I do have to add a caveat to @TheVelozGroup’s response to the wifi reliability question. It is true that TCP is more reliable than UDP, by design. However, wifi as a protocol is not as reliable as a hardwire connection and is prone to noise and interference. If your application cannot tolerate disconnects, then a non-wifi solution may be required.
Am I correct in assuming your PC/Tablet application can ONLY talk via serial/current loop to the machines? Also, is each machine on a separate loop or on a single loop using an addressing scheme?
In my opinion, the first issue is moving the control software from a serial I/F protocol to TCP. This has to be done by the program since the tablet will ideally not need to use the OTG connector. Any thoughts on that?
The system is tolerant to a certain extend as we currently poll the machines and if we do not get a response we will continue and come back later. However the information is critical and must be correct. The machines are fuel pumps at a gas station. We cannot control what vehicle pulls up at the pump and how it may interfere with the comms. The main thing is the comms must not be stopped by interfere for long periods.
At present we only use a PC—>Serial---->Current Loop---->Pump. We dont use a tablet currently because of the serial port/charging problem.
Our interface hardware currently only supports serial. Moving to TCP now, with the current hardware would not gain much. I would really like to move to wireless to make the installation easier. Laying cables is a pain.
I am looking for a wireless communications platform to start with, but later could add more intelligence at the end point to handle more of the comms and minimize the comms back to the pc.
Just have to take into consideration that now still the case if you lose connection to the internet is blocked the execution of the cycle. There is an option to turn off the connection to the Cloud. But also may cause some blockage in the router. For critical applications I think Wifi connection is not exactly the most appropriate …
I think that for this type of application is the most suitable solution is by using Xbee modules.
I may be just stating the solution you may have thought about already.
Given the following may be the ideal design you may want to see:
PC/tablet -> wifi -> photon -> serial -> current loop -> machine
Given the interference on the Wi-fi, would you want consider having caching/recovery mechanisms in your PC/tablet software? If the data communication has to be close to real-time, this is not the right solution…
Other option is look at XBee as @developer_bt suggested However, you may want to use the Xbee 900 MHz version as the XBee 2.4GHz version could have the same interference issues as Wi-Fi.
Are there any boards out there which have arduino and xbee combined on one board, similar to the Spark.
Arduino and xbee start getting quite expensive.
I think Particle is compact compared to Arduino (atleast the versions of Arduino we used). Also if you decide to use cloud functions, Particle is better.
We haven’t across a single board of Arduino with Xbee. We used an XBee shield with the Spark core module for one of our prototype projects. Also, please note that not all versions of Xbee support mesh. Here is a link that may be useful