Anyone willing to help out on a small project?

[[)roi(]]

If you're building "lazy & bad UX" on a web application, then that's exactly what you are - a lazy and bad developer. I've built web applications for clients with the slickest, cleanest and friendliest UX you can imagine. It all boils down to a developer's competence with HTML, CSS and JavaScript. When you've been doing it long enough, you started building your own libraries and frameworks to fast-track your own development whilst delivering native-class UX for your users. You could just as easily build a bad native app if you don't have a firm understanding of the technology at hand.


...and similarly I don't always ascribe to a web application. Horses for courses and all that. I'm not going to go into a language-pissing contest, but I've also used my fair share of programming languages in a wide variety of applications to feel comfortable in making recommendations to clients.


Again, it depends on your grasp of the technologies at hand. Web applications can be deceptively simple if you use the right libraries and frameworks. Again the same argument can be made for native applications, where the complexity quickly ramps up with server API's feeding data to the thin clients, security often not being implemented properly and, once again, deployment and maintenance after go-live.

The development industry is very much an economy on its own - the reason why there's so much discussion surrounding it in the local (and international) scene, is because there's such a huge demand for it. Even when you're building a native application connected to a central server, you in essence have a "web application" (sans UI) providing consumers with data and business logic (if you're following a SOA approach). So the interest and number of discussions surrounding web applications will always outnumber those of native applications, because that's the nature of modern applications and everything wanting to be part of the IoT.

It really doesn't matter how good you are or not; there's a limit to what can be done to overcome web app issues; apps just don't have the same limitations.

As to a bad developer and bad UX; I'm ignoring that, because we talking about everything being equal i.e. good web developer vs good app developer; there will always be many scenarios where the web developer should step back and not build; but sometimes a client is insistent and you end up with e.g. bastardised versions of Sharepoint that nobody wants to touch for fear it's going to break.

Yeah we all know backend is built on web tech; but let's not be ridiculous by trying to include that; the entire discussion has been about frontend; Anyway a well designed backend will support multiple frontends without any change (web + app) i.e. the right way to design the backend is to make it completely independent of the frontend; sadly too many make the mistake of tightly integrating the two.

The overall problem that is both prevalent on this forum and in South Africa (more so than internationally) is that Web development is still a very big thing ito front-end UX (and I'm not talking about websites, but rather web apps); a number of factors contribute to this in SAs specific case, but that's a whole debate of its own, for example: why is SA still employing so much old and redundant tech? Sadly its a sign of how untech our society is versus the rest of the world; who aside from Africa still Blackberry in business.

Side note: As to me slating Javascript; I do this to point out it's inherent flaws, those which are specifically not be present in other languages + to raise my frustrations with the lack of any compilers that can enforce lexical or style rules. Many Javascript developers (new developers that started out with web) get to a point where they believe they're great programmers, but almost everytime I reviewed some this code; I'm near to wanting to pull my hair out for the lack of clear e.g. var definition, type observance, SRP, no test code,... These guys could certainly benefit from learning a lexically correct language.

 

[Spacerat]

Wow walls of text! But seriously, excellent contributions and arguments.

The project is about integrating devices on a factory floor. So for instance, at a particular work station the use case is as follows: the user scans an item's tag with a unique identifier and places the item on a scale. That's it. Then the next one, and next one. This info (id & weight) needs to be posted to a business process type function on the server that updates stock, etc etc. So we have 2 inputs: the tag id from a barcode scanner, and the weight from the scale. The scale is headless, meaning it has no display. The order in which the user performs the actions is important because the weight from the scale triggers the submission. The user does not interact with the system in any way apart from handling the items as described. But for the sake of showing the user what is happening (handling errors do occur) , and whether the operation is successful, I want to give him a head ('remote display') that displays id & weight and error messages. That's it. No user input. There are several (~7) of these work station use cases, each subtly different from each other, down the production line

O, and some other considerations:
- The (private) organisation does not have dedicated IT people, so the solution needs to be brainless in simplicity...
- Internet connectivity is virtually non-existent
- The factory is washed by hosing everything down
- Very tight budget money-wise and time-wise
- I have no experience in developing Xamarin / Android
- You buy a ruggedised Android tablet for R3K. Bought 3 for experimenting with

So in terms of the system design, there are a few options:

1)
Put a rugged PC at the work station and connect it with serial cable to scale and barcode scanner. Write the software to run locally
Pros:
Easy to develop a desktop type app to read serial ports and call server-side
Easy cabling from scale & scanner to local PC

Cons:
Specialised hardware requirements expensive as it needs to be IP rated. Hardware do break down so need to carry spares
Swopping out hardware means redeploying apps & config etc etc
Overkill for what needs to be done


2)
Do everything server-side, but give user a 'remote display' to see what is going on. Cabling not so difficult: run serial cables to Ethernet Port Server and then get virtual serial ports on server. Apps run on server so server-side calls are local.

Pros:
All apps deployed server-side only
No need to hardware at work station (except display)
Solution is not dependent on work station side PC hardware (display is nice to have)

Cons:
In the absence of a display, the user could make mistakes.

EDIT
3)
Use IoT concepts: Deploy R-Pi at work station in a plastic box and call server-side.

Pros:
Easy to ruggedise R-Pi
Local cabling
Do IoT real-world applications

Cons:
Localised deployment of app
Engineering required to put R-Pi in a IP box and then support it for x years afterwards
Still requires display of some sort

So, I have chosen option 2, To address the con, I am wanting to put up a head for users to see what is going on. But the system must still work if the display is not there. So, given the above considerations, I would prefer the display to have zero deployment. This is where the rugged tablet comes in. The tablet will connect via WiFi, so no cables. Only a bracket on the wall. If need be, they can remove it prior to washing down. Seeing that all the apps will run server side, the idea is that each app runs a websocket server. Then when the tablet is switched on, there is a simple page @server root with links to each function. The user can select a function and that page will represent the display for that function and open a link to the web socket server in the appropriate app. This allows the app to send data to the display as it happens. If the tablet does not log on, no info is sent and the app carries on doing its thing. If they move tablets around or remove them after the days use, there is no issue with pairing the tablet with the right workstation the next day. If you have apps on the tablets then you have to have all the apps on all the tablets. And when you do updates, you have to deploy the latest on all apps. Not great if you are sitting 1000s of km away.

 

[Spacerat]

PM sent

Replied

 

[[)roi(]]

In the scenario you describe it sounds a lot like the work I did for Petrol Stations; environment is hazardous to most IT kit: water, chemical, etc...

The best solution was always to centralise on a single controller: we used an industrial embedded controller (primarily because they're solid and supported >10 years), but it could quite easily be a server with a multi cards: serial, etc... (that's btw what was previously used)

In our case the application that interfaced with the controller was kept on site primarily because we needed operations even when site communication was down, however these types of units can easily be interfaced with remotely & they not limited to only displays; we tied them into electronic scales, forecourt pumps, tank gauging, fridge temperature sensors, attendant tagging, EFT vehicle tagging, etc...

Note: a standard Windows PC with multi cards could do this.

As to the information; we used simple IP66 multi-line LCD displays; no reason to put computer kit there if you don't need it, these units rarely fail; we have ones working for well over 10 years, and no issues + when they do fail it's a simple replacement i.e. standard RS232 or RS485 type interface. Usage is quite to what you see at most supermarket cashiers; but if more information is needed you naturally would need a slightly larger display, however information could be shown at different stages i.e. when you place something on the scale it shows the weight only; when you scan it shows the barcode / item #, the weight & the price?

In short: I think a site server + cabled displays is the simplest / cheapest to maintain.

 

[Spacerat]

In the scenario you describe it sounds a lot like the work I did for Petrol Stations; environment is hazardous to most IT kit: water, chemical, etc...

The best solution was always to centralise on a single controller: we used an industrial embedded controller (primarily because they're solid and supported to >10 years), but it could quite easily be a server with a multi cards: serial, etc...

In our case the application that interfaced with the controller was kept on site primarily because we needed operations even when site communication was down, however these types of units can easily be interfaced with remotely & they not limited to only displays; we tied them into electronic scales, forecourt pumps, tank gauging, fridge temperature sensors, attendant tagging, EFT vehicle tagging, etc...

As to the information; we use simple IP66 multi-line LCD displays; no reason to put computer kit there if you don't need it, these units rarely fail; we have ones working for well over 10 years, and no issues + when they do fail it's a simple replacement i.e. standard RS232 or RS485 type interface. Usage is quite to what you see at most supermarket cashiers; but if more information is need you naturally would need a slightly larger display.

Tx, yes very much similar by the sounds of it. The issue is of course always support and obsolescence. The idea for RS232 LCD display is also a very good one. Can you give me more details on these? The software apps are structured so that the interface is a plugin that is loaded, so I can deploy and interchange any type of display down the line.

 

[[)roi(]]

Tx, yes very much similar by the sounds of it. The issue is of course always support and obsolescence. The idea for RS232 LCD display is also a very good one. Can you give me more details on these? The software apps are structured so that the interface is a plugin that is loaded, so I can deploy and interchange any type of display down the line.

The service station have a similar issue re obsolescence and support; typical required lifespan of systems (including scales, displays, ...) is >10 years, often running to >15 years; and on some of the parts we secured contracted support including parts for up to 20 years.

Support consideration / idea:
There are a few companies that provide support to the Service Stations country wide, and as you know Service Stations are pretty much located everywhere; so you may want to consider building the solution with them re:

• It's very similar to what they already maintain.
• ...and they have "man in the van" technicians everywhere.

Alternatively you could also contract with any of the companies that support the supermarket guys; many use the same ones as the service stations.

I've been out of touch of that industry for a few years, so I'd have to confirm some contacts for you; but it certainly doesn't sound too complicated from a support POV.

Development
As for the backend development you could still contract the build with someone skilled in your backend OS e.g. Microsoft or Linux guys. All the developers would really have to learn is how to write code for the serial port interface (there are some commercial or open source frameworks that make this easy).

I'm not sure how your scale connects, ours were Teraoka scales with an ethernet port which interfaced via TCP/IP with control software on the server (Teraoka provided), so again our scale communications were controlled on the server; meaning it's was pretty easily to relay the sensed weight back to the digital displays in realtime. Barcode scanners should similarly be easily.

If that sounds like something you want to explore; I'll try to dig out some of our connection diagrams, naturally you would need to adapt this for your environment. Plus I'll get onto getting support contacts for a few companies you may want to consider for the build / installation / support.

Note: The build is no longer my forte, but I'm happy to give free advice + put you in touch with companies that can make it happen.

Addition: I missed a question re the interchangeability of the displays:

• This really comes down to the type of display and the driver (if it's the same, it's simple plug and play); if it's a new one, then in most basic cases you would be given instructions on how to interface with the device; and that you would encapsulate as a software driver (it would comply with the standard server interface), replacing this basic solution would mean replacing the driver (either vendor provided or something you write; it's doesn't have to be a Windows driver; it could just be a simple background service that handles the port communication. It's not rocket science).
• The same should apply to your scale and scanner interface i.e. you are either provided a driver or you have to build it yourself.
• The only suggestion I would have is for you to standardise the server side interface i.e. adding a new display should only require adaptation of the driver to the server interface i.e. you never destabilise the server code when you're bringing in replacement displays, scanners, etc. In the petroleum industry they standardised this under their own standards board IFSF -- for you I would not advise this; it's large, complicated, and focused solely on petroleum requirements.
• In short you build your own server side interface standard & adapt the device drivers to this; that way you'll maintain the code and you avoid vendor lock-in. Naturally this can be outsourced.

 

[Spacerat]

The service station have a similar issue re obsolescence and support; typical required lifespan of systems (including scales, displays, ...) is >10 years, often running to >15 years; and on some of the parts we secured contracted support including parts for up to 20 years.

Tell me about it. Our applications run for typically > 25 years as it is pretty niche. So you have to keep the dev environment alive.

Support consideration / idea:
There are a few companies that provide support to the Service Stations country wide, and as you know Service Stations are pretty much located everywhere; so you may want to consider building the solution with them re:

Software support I do remotely, hardware obviously you cannot. Here I recommend the customer uses local suppliers for scales etc so that the suppliers can honour their warranties etc. The project is currently a pilot so only one site at this stage. I also try to use as much commercial off the shelf components in order to manage long-term obsolescence.

Development
As for the backend development you could still contract the build with someone skilled in your backend OS e.g. Microsoft or Linux guys. All the developers would really have to learn is how to write code for the serial port interface (there are some commercial or open source frameworks that make this easy).

I run my own SW Dev company so dev skills not an issue at all. I have done a similar system for another factory, but this time around the environment slightly different and lessons learnt.

[*]The only suggestion I would have is for you to standardise the server side interface i.e. adding a new display should only require adaptation of the driver to the server interface i.e. you never destabilise the server code when you're bringing in replacement displays, scanners, etc.

[*]In short you build your own server side interface standard & adapt the device drivers to this; that way you'll maintain the code and you avoid vendor lock-in. Naturally this can be outsourced.

Yep, everything is a plugin and abstracted with interfaces, so various scales support, different barcode formats, display interfaces, RFID readers are just pluggable by means of a config (manifest) file and dynamically loading the assembly. So supporting a new scale is just writing the driver/parser and compiling the assembly and then configuring it to load.

 

[[)roi(]]

Tell me about it. Our applications run for typically > 25 years as it is pretty niche. So you have to keep the dev environment alive.


Software support I do remotely, hardware obviously you cannot. Here I recommend the customer uses local suppliers for scales etc so that the suppliers can honour their warranties etc. The project is currently a pilot so only one site at this stage. I also try to use as much commercial off the shelf components in order to manage long-term obsolescence.



I run my own SW Dev company so dev skills not an issue at all. I have done a similar system for another factory, but this time around the environment slightly different and lessons learnt.




Yep, everything is a plugin and abstracted with interfaces, so various scales support, different barcode formats, display interfaces, RFID readers are just pluggable by means of a config (manifest) file and dynamically loading the assembly. So supporting a new scale is just writing the driver/parser and compiling the assembly and then configuring it to load.

Sounds like you're well equipped to tackle this. If you like I could try to put together a diagram of how I envisage the communications & abstraction to work. Naturally you would need to identify all the varieties of scales & scanners in use, so that you could source 1 of each to build the drivers / abstraction interface.

As to the hardware management; we built monitoring into the service abstraction, simple plugins added details to a JSON file that was relayed to the central office (Simple Custom built Timed FTP Windows Service with a ruleset), basically to allow us to remotely monitor if equipment was functional or not; e.g. we could identify when a serially connected customer display was faulty, which made dispatching of support crews easy from the central office, but we also added plugins to monitor usage i.e. identify idle equipment , etc...

 

[Spacerat]

Sounds like you're well equipped to tackle this
If you like I could try to put together a diagram of how I envisage the communications & abstraction to work. Naturally you would need to identify all the varieties of scales & scanners in use, so that you could source 1 of each to build the drivers / abstraction interface.

Tx, you are welcome to do so. Most of the dev has already been done though. I have built most of the scale plugins for the previous integration project.

 

[[)roi(]]

Tx, you are welcome to do so. Most of the dev has already been done though. I have built most of the scale plugins for the previous integration project.

Yeah no worries; the idea is not to radically alter course but rather to hopefully frame the idea + most of what you describe sounds anyway like a perfect match for what I had in mind -- since your more detailed explanations.

 

[[)roi(]]

As promised...

1. Genuino (Arduino) or similar component computer
In this scenario you can either make the arduino serial control code light and run the most of the control from the server *http connection using e.g. AJAX, alternatively you could build a bit more intelligence at the Arduino level and only send pertinent bits back to server i.e. contain handshaking.

• This option requires component computer with multi serial ports; 1 for each device
• This option does afford you the greatest level of flexibility but at a cost (install & maintenance)

The benefit of this solution is that serial cabling is contained at the work area and only 1 ethernet cable needs to run through the warehouse, however even that can be eliminated by using e.g. power over ethernet adapters.
The negative aspects of this approach is that you now have a few more bits and pieces to maintain and of course the code on the Arduino.

2. Serial wire everything to the site server
The option requires that the serial control all happen on the server.

• The server has to have a large bus to contain multiple port serial cards re all the wiring will terminate at the server.
• A lot of conducting is probably going to be needed to run the serial wiring back to server, and you may want to consider serial junction boxes to neaten things up a bit
• Electrical impedance can be an issue if run this alongside power, etc..
• As for the multiline LCD display; I've used these in component form and complete units: there are many options available, and it's never a huge challenge to get these to work. Plus they're solid and hardly ever fail, assuming of course you've got surge protection on the electrical side.

Pro: This is pretty much an old, tried and tested solution without any bells and whistles.
Con: Problems are probably only electrical impedance (managed), greater electrical surge risk (managed); server with a large enough bus capacity for the cards (usually 4 to 8 ports per card).

Longevity
Possibly the biggest challenge with whatever you choose is the 20+ year lifespan, there's not many technologies that can guarantee to be working for that long; even multi-port serial cards may be a problem to source; certainly component computers like Arduino and Raspberry PI will have long been replaced by new tech; it's anybody's guess how long the boards will last.

If your investment needs to be secured for that length of time, then you probably want to source a solution from a vendor that guarantees this; for example: DOMS in the case of service stations guarantees their controllers over extended periods, but still nothing approaching 20+ years.

 

[Spacerat]

As promised...
View attachment 359114
2. Serial wire everything to the site server
The option requires that the serial control all happen on the server.

• The server has to have a large bus to contain multiple port serial cards re all the wiring will terminate at the server.
• A lot of conducting is probably going to be needed to run the serial wiring back to server, and you may want to consider serial junction boxes to neaten things up a bit
• Electrical impedance can be an issue if run this alongside power, etc..
• As for the multiline LCD display; I've used these in component form and complete units: there are many options available, and it's never a huge challenge to get these to work. Plus they're solid and hardly ever fail, assuming of course you've got surge protection on the electrical side.

Pro: This is pretty much an old, tried and tested solution without any bells and whistles.
Con: Problems are probably only electrical impedance (managed), greater electrical surge risk (managed); server with a large enough bus capacity for the cards (usually 4 to 8 ports per card).

Longevity
Possibly the biggest challenge with whatever you choose is the 20+ year lifespan, there's not many technologies that can guarantee to be working for that long; even multi-port serial cards may be a problem to source; certainly component computers like Arduino and Raspberry PI will have long been replaced by new tech; it's anybody's guess how long the boards will last.

If your investment needs to be secured for that length of time, then you probably want to source a solution from a vendor that guarantees this; for example: DOMS in the case of service stations guarantees their controllers over extended periods, but still nothing approaching 20+ years.

Thanks...

I am using option 2. But I use serial port device servers. http://www.digi.com/products/serial-servers/serial-device-servers
Basically RS232 wiring remains local and then this device just connects to the network. On the server the device's driver just creates virtual COM ports. Easy as pie. Can connect any number of these devices. So no issue with running multiple RS232 cable over long distances and having to source multi-serial cards (which are becoming hard to obtain already). In my previous similar solution that I did 16 years ago, these devices are still in operation. One did get taken out by lightning once.

What I like about option 2 is that the component count is low and is easy to source. Thus less chance of failing and easier to maintain.

 

[[)roi(]]

Thanks...

I am using option 2. But I use serial port device servers. http://www.digi.com/products/serial-servers/serial-device-servers
Basically RS232 wiring remains local and then this device just connects to the network. On the server the device's driver just creates virtual COM ports. Easy as pie. Can connect any number of these devices. So no issue with running multiple RS232 cable over long distances and having to source multi-serial cards (which are becoming hard to obtain already). In my previous similar solution that I did 16 years ago, these devices are still in operation. One did get taken out by lightning once.

What I like about option 2 is that the component count is low and is easy to source. Thus less chance of failing and easier to maintain.

great option re serial port servers, basically the same concept as the DOMS solution we used for the service stations, also connects back to the server via IP network. Simple but effective and yeah that makes it far easier maintain. Lightning can be quite a challenge to overcome in certain areas.

Simple is always best, the last solution I replaced was running OS/2 for just well over 20 years; the newer one has been running since 2009 and looks to be a winner.

Anyway good luck.

 

[Spacerat]

great option re serial port servers, basically the same concept as the DOMS solution we used for the service stations, also connects back to the server via IP network. Simple but effective and yeah that makes it far easier maintain. Lightning can be quite a challenge to overcome in certain areas.

Simple is always best, the last solution I replaced was running OS/2 for just well over 20 years; the newer one has been running since 2009 and looks to be a winner.

Anyway good luck.

tx