Archive for the ‘Industry’ Category

Programa a tua vida

Quinta-feira, Março 28th, 2013

O post do Pedro Cardoso sobre o vídeo que anda por aí sobre o ensino/importância da programação fez-me querer escrever sobre a minha própria experiência.

Tive o meu primeiro computador aos 4-5 anos. Era um Timex Computer 2068, um maquinão na altura! Claro que inicialmente jogava alguns jogos que o meu pai me arranjava, mas mais tarde comecei a introduzi-los à mão de listagens em revistas (principalmente a Your Sinclair) e livros. Cheguei a modificar alguns jogos, e a fazer um que tinha um boneco e umas arvores no ecra (não me lembro qual era o objectivo, se havia um :) ). Foi uma coisa progressiva, e não me lembro quando nasceu a minha paixão pela programação.

O evento “abre-olhos” foi mesmo quando convenci o meu pai a comprar-me um Amiga 500. Estive um ano a chateá-lo, e ele obrigou-me a vender o Timex para comprar o Amiga! Mas aquilo era qualquer coisa de fora do comum… toda a indústria informática levou anos a apanhar o que o A500 conseguia fazer. Fiz algumas coisas pequeninas, e iniciei um jogo em BlitzBasic (o Vapour Trail). Já naquela altura programava “por objectos”, e desenhava as minhas naves e edifícios em 3D (usava o Imagine, Real3D e, mais tarde, Lightwave3D). As revistas da altura (Amiga Power e Amiga Format, ambas da Future Publishing) ajudavam bastante, e já na altura comprava software na Inglaterra (através dos anúncios das revistas).

Depois das BBSs (sim, sim, modems a 9600 bps e modo texto!), a web nos Amiga era muito utilizada (via modems também); a Aminet era o maior repositório online (e offline através dos CDs) de software com sources de Amiga, assim como o Amiga Web Directory era o nosso Google, e o pessoal era muito unido e partilhava o conhecimento de uma forma que hoje já não acontece. Bons tempos!

As coisas eram mesmo como o Pedro diz: se a vida te dá limões, faz limonada. Havia muito pouca coisa em português na altura, as revistas, livros, manuais, BBSs, websites, etc, eram quase todos em inglês; em pouco tempo eu já pensava em inglês, à noite, na cama!

Como eu tinha muito interesse pela modelação e renderização 3D, não me dediquei inteiramente à programação na altura. Queria fazer tudo: os gráficos, o som, o código. E jogar. Sim, porque os jogos no Amiga eram fantásticos, e eu tinha grandes amigos para o fazer comigo!

Com o tempo, descobri que a programação é mesmo o meu vício. A magia da tecnologia inspira-me. Hoje não tenho medo de programar nada, muito pelo contrário, é um desafio. De microcontroladores a computadores, passando por telemóveis, PLCs, marcha tudo. Acabei por ir parar à área da indústria, onde me fascina ver o meu software a controlar e supervisionar fábricas com máquinas enormes e poderosas, capazes de produções alucinantes. Às vezes fico ali no meio da fábrica, a apreciar tudo aquilo a funcionar, quase a ouvir os bits do meu software a transformarem-se em azeite. Ou vinho. Ou outra coisa qualquer que, amanhã, vai estar na tua mesa.

Mas eu acho que tive sorte. Um computador aos 5 anos, não era normal. Hoje é, mas não da forma que era antigamente, já não é preciso programar nada para utilizar bem um computador. E assim, tenho um projecto em curso de ensinar programação (e electrónica) a míudos (e graúdos também). Umas workshops de robótica, que espero eu inspirem os mais pequenos a entrar no maravilhoso mundo da ciência e tecnologia.

Assim nasceu a Intellego.

No display, no go

Terça-feira, Setembro 11th, 2012

In a recent telemetry project, I selected a very small form factor, low power consumption computer to tackle the task of sending data from a factory to another. Since Raspberry Pis and look-alikes are still difficult to source quickly, I went with an industrial solution (an Advantech ARK 1120).

Since the machine was to stay put doing it’s job 24/7/365 on a Windows network, connected to the SCADA environment, I decided to go with Debian as the OS. But since the machine only had a 4GB CF card as mass memory, I wasn’t able to install a simple Netinst image, selecting only the Desktop environment “package”. That’s because ticking that simple choice brings the system requirements to 4.4GB. Yes, 4.4GB minimum.

I must be getting old; I seem to remember a time when doing a simple install of Debian was a cool experience. One in which you selected exactly what you wanted to install, over a very simple and small base system. The base system is still there (command-line based, of course). But the next notch up the scale weighs in at a mammoth 4.4GB.

I must admit the requirements for this project were almost begging for a Windows machine (the client wanted the machine to have a desktop system, and to be accessible via TeamViewer), but I feared for it’s health. So I preferred a Debian-based machine, but 4.4GB for a “basic” desktop environment system?

Ok then, let’s do this the hard way. I knew I was in for a treat, because my Linux skills have been used superficially for the last half-decade. Still, I thought installing a basic Debian-XFCE system and a couple of accompanying utility packages couldn’t be too hard. So, let’s install:

- Debian from a USB memory stick
- XFCE
- unzip, sudo, nano, SSH, Samba, text editor (NEdit), file manager, IceWeasel… they weren’t kidding when they labelled it “basic”…
- TeamViewer
- x11vnc
- JRE
- my app
- edited inittab and .bash_profile to configure autologin on boot
- created an autostart script in XFCE, starting up my app on boot

1.5GB on disk, that’s cool. The resulting system is quick and nimble, apears to work great.

But alas, when I remove the (VGA) display, keyboard and mouse, the machine does not startup properly! No SSH, no VNC, no XFCE autostart scripts (obviously). It seems to be related to the desktop manager not finding the display. Doh! I confess I don’t ever recall booting a Linux box (with desktop environment) without a display, but I wasn’t expecting this behaviour. I’ll try it out at home and see if it’s a common thing on Linux (I’m pretty sure my RaspberryPi does boot without a TV, and Windows boots whether it has a screen or not).

On a different note, I was expecting a lot more included on a basic system by default (Samba, SSH, vim/nano, unzip…), but I guess the “basicness” can be considered good to start a system configuration (that’s exactly what I love about TinyCoreLinux, for example). Still, I believe the next step (desktop environment: 4.4GB!) is waaaaaaay off the charts! The sweet spot, in my opinion, would be a CD-based desktop Debian system, with all the basic utilities one usually need on an OS (Samba, FTP, SSH, VNC, archiver, text editor, basic music/video player, basic browser, etc), but no full-fledged applications at all (no Office apps, no games, no graphics apps, no creative apps, etc). I believe you could keep it under 2GB easily.

I’m sure a distro like this exists. If you’re reading this and know such a distro, please comment! :)

Hot Swap

Sábado, Janeiro 7th, 2012

One thing I’ve been absolutely jealous of the PLC world is the ability to hotswap DataBlocks, FCs, etc. I mean, while the PLC is running and executing code, you can simply upload a modified version of an FC (basically a function) and… it just works. The PLC (once the upload is completed) changes the function pointer to the new code between cycles, and all is well.

Obviously, PLCs are rather simple functional machines, they basically work with static memory blocks (for variables and functions) and with a very rigid structure (IN/OUT image management, main cycle). So it’s very easy to achive the hotswapping of functions, and even of variable blocks (you basically refer to a variable by it’s address; if you’re not carefull changing a varible block, you might be now pointing to some address that encompasses parts of two variables… it does not complain).

When you mainly roam on Java land, like I do, the sights change dramatically. Sure, you have an immense power on your hands, but think about class hierarchies, objects, constructors, third party libraries… and it’s very far from trivial to implement hotswapping in the Java Virtual Machine.

I’m using Java to build my most important “desktop” applications (actually, it’s a server-client aproach, but the server app is 100% built by me, no third party web or app servers involved), and sometimes I’d like to have hotswapping on my development system. It really bugs me to have to bring down my server app because of a simple bug fix or improvement.

Still, after reading a bit on HotSwap, JRebel and the like, it probably is not that important. I’m not willing to add significant amounts of complexity just to gain hotswap, since I’ve developed things with a very lightweight and encapsulated structure. On recent hardware and JRE, my server app starts up in 8 seconds (database startup included), and the client app in a mere 4 seconds. Even with a full recompile and shutdown times, I’m looking at a power cycle of under 30 seconds. Not bad.

VirtualBox and greater screen resolution on the Guest

Terça-feira, Julho 12th, 2011

If you’re in the automation field and work with Siemens WinCC software, you have most certainly got projects with different screen resolutions; and screen resolutions are chosen and fixed on the design side. Wich means that if you have to work on a project in a computer with a smaller resolution, you simply can’t see all of the WinCC runtime screen.

Nowadays, I work from my MacBookPro and virtualize Windows and Linux everytime I need them for testing. This is also a very confortable way of dealing with these Windows-only situations like WinCC, but if you’re on VirtualBox and need a higher resolution to work with WinCC (1280×1024 in my case), you’re in trouble. That’s because by default VirtualBox does not allow the guest Windows to pick a resolution greater than the host OS’s.

There is a simple solution, although a bit burried in the manual: just copy-paste this into the terminal:

VBoxManage setextradata global GUI/MaxGuestResolution any

, and suddenly (well, after a guest OS reboot) you can pick humongous resolutions if you want. Then, activate the Scale Mode (Host key + G) and away you go!

A iluminação Pública sobre outra luz

Terça-feira, Dezembro 7th, 2010

Não é meu costume, mas aqui vai um link para um video que demonstra como a iluminação pública devia ser:

ArquiLED

Espero que neste país comecem a investir mais em coisas que valham a pena, e não apenas a esbanjar dinheiro em coisas estúpidas, que parecem ser “inventadas” só para encher os bolsos a determinados amiguinhos (como os painéis de aviso dos preços dos combustíveis nas auto-estradas, ou ainda pior, os sinais que avisam com 8 km de antecedência que os painéis vão aparecer… ).

AmigaOS unchained

Sexta-feira, Outubro 23rd, 2009

It has finally happened! It’s great news to see AmigaOS free from it’s legal disputes! Hyperion seem to now have full rights to develop it for whatever hardware platform they desire.

I hope they give the OS a clear roadmap, even if it is primarily targeted to a niche market (like the embedded one, where I think it could have some following). And I also hope they realize that their most probable early adopter userbase will be us Amigans. We nerds that had Amigas 10-15 years ago, and that now have twice that age at least. I think they need to target us first.

Like I’ve seen the honorable Zetr0 say on EAB, the boing ball is on their side now. Let’s see what they do with it!

OPC - OLE (Open?!) Process Control

Segunda-feira, Março 9th, 2009

In my industrial meanderings, I’ve been using some I/O modules for wich I write device drivers (for my data layer abstraction). One of these involves the OPC protocol (OLE for Process Control). It’s actually a pretty good ideia (badly implemented).

The ideia is that all data devices should be easily accessible by a standard communications protocol. There’s the ideia of an OPC server, an application that connects to the devices and exposes their data on the OPC protocol. Then, an OPC client connects to these servers and reads/writes on those devices. The problem is that they based OPC on a Microsoft-only (thus Windows-only) technology, DCOM. DCOM has a history of being difficult and picky to configure remote access and, because of this, almost nobody goes to the length (and risk) of configuring a system remotely (permissions problems, etc), and clients and servers are usually run on the same machine (defeating half the purpose).

Still, the ideia is too good to let go, and there are OPC servers for almost everything on the market. Getting OPC to work was one of my first projects at work, but since I write almost everything in Java (so that it runs on Windows, Mac and Linux) I had to find a way to get access to OPC from Java.

Back then, I developed a small TCP/IP proxy, socket-based, with a simple ASCII protocol, on Visual Basic (using the native OPC DLL). It not only brought along the lost OPC purpose (distributed access), but I could have access from just about anything (Java, Ruby…). Still, it was slow, configuration was local, and it did not implement all of the OPC protocol.

Later, I found almost exactly what I was looking for: a couple of companies were proposing JNI-based Java wrapper libraries, giving access to OPC. The problem: they cost as much as the OPC server (about 600 Euro) and, just like the server, I had to purchase one library license for each deployment.

I never understood this business model; I would hapilly buy the library once and deploy to my hearts content, as this would probably be cheaper than developing the library myself (I do this with JFreeChart, for example). But if I have to pay for every deployment this is simply not economical, since with the money of 2 or 3 deployments I was definitely able to develop the library from scratch. I was seriously thinking of developing the library myself and selling it with JFreeChart’s business model (I had no competition anyway), until I found JEasyOPC.

Antonin Fisher developed an OPC wrapper library based on JNI (and Delphi) and offered it with a LGPL license. I’m testing the library now and it seems to perform very well on Java 5. It crashes on Java 6 though (apparently due to multithreaded issues).

If Antonin ever gets around to fix this issue on Java 6, we’ll have a winner! :)