Author | Topic: Michael's Xbase++ OOP Survival Manual, Part III | |
---|---|---|
Michael Hoffmann | Michael's Xbase++ OOP Survival Manual, Part III on Sun, 02 Nov 2008 12:10:31 +0100 Hello fellow developers, I just updated the Cockpit site (News and Future Events sections) and added some information on what I'll be speaking about in my presentation at the Xbase++ Party in three weeks in Holland. See www.xcockpit.com. Best regards, Michael | |
Osvaldo Ramirez | Re: Michael's Xbase++ OOP Survival Manual, Part III on Mon, 03 Nov 2008 21:07:38 -0700 Heloo Michael Hoffmann Please, tell me more about "Tom" device. I would like to know, what kind of app are running that use this device. and how it is connected to Cockpit lib. Good luck in Holland, I would like to be there, but the economy word is down, anyway ... see you sooner or later. Best Regads Osvaldo Ramirez | |
Michael Hoffmann | Re: Michael's Xbase++ OOP Survival Manual, Part III on Thu, 06 Nov 2008 19:22:48 +0100 Hello Osvaldo, > > Please, tell me more about "Tom" device. > > I would like to know, what kind of app are running that use this device. > and how it is connected to Cockpit lib. Currently we have two applications that use the Tom device. The first application monitors a production line. It is attached to a machine which sends impulses about the state of the machine (stopped, running, automatic mode) and an impulse whenever one product was finished (in fact it can be more complex). The application then calculates the production speed, compares it to a speed that should be maintained, warns the operator if he is producing too slowly. It also forces the machine operator to enter a cause if production is stoppend for longer than a given interval. Futhermore the addition of new raw material(s) is monitored and lot numbers are recorded. In addition, this application is controlling an ink jet printing device that marks every piece produced with the machine ID, a time stamp and the product description text. In this case Tom is connected to the machine controlling electronics using 24V lines. Of course this application also records the operator, who will soon be able to identify himself with his transponder. All this happens in a bigger production planning system which is also connecet to a backend SAP system. The other application was written for an "office of public health" (Gesundheitsamt). It controls the "Sagabude" a device very similar to those booths that can be found at fun fairs where you have to throw balls at things to win something. The Sagabude has 12 panels you can hit with balls you throw. Depending on the configuration loaded into the device you must hit only correct panels. For example, you must mix a cocktail only with non-alcolholic ingredients. So it's OK to hit banana juice, but hitting whisky will blow you out of the game. During the game the device instructs you what you have to do (spoken text), if you are doing fine or not and it tells you when you've lost and won. The device is also equipped with different kinds of light effects controlled by our software through the Tom device. There are different configurations that can be loaded for different topics: Information on Aids infection ways, Contraceptive methods, alcohol prevention, ... This device is big fun and attracted many viewers while I tested it in my garage. And, to be honest, it hurts when it calls you a loser because you always miss the panels.... Cockpit is required for the communication between the Tom device and the PC running the controlling software. In fact it's a serial connection over a USB device and we're using the standard O/S calls for configuration and I/O. Further down I attach the Tom class declaration in case your're intereted in more details. > > Good luck in Holland, I would like to be there, but the economy word is down, anyway ... see you sooner or later. Thanks. I'm looking forward to seeing you again, soon! Best regards, Michael --- snip --- SECTION CLASS Tom ***************************************************************************** The Tom Class ***************************************************************************** CLASS Tom EXPORTED: Serial COM port for communication with Tom VAR comPort VAR commandTimeout Inport state VAR inPortBits && 16 bits (0..15) * Outport state VAR outPortBits && 9 bits (0..8) The thread taking care of all incoming messages VAR listenerThread The event queue VAR eventQueue * The reply to an external request VAR replyType && "Semaphore" variable, when it's # NIL, a reply was received, && ::replyInfo must set before setting ::replyType VAR replyInfo && Set before setting replyType control of the listener thread VAR stopListener VAR notificationSinks A block to be executed in the listener thread when an event occurs VAR eventFilterBlock * Array of 16 numeric elements, 1 for each inport bit, or NIL VAR inCounters The object handling transponder events VAR transponderHandler EXPORTED: CLASS METHOD Connect SYNC METHOD Disconnect SYNC METHOD SetOutBit SYNC METHOD GetEvent SYNC METHOD GetTicks SYNC METHOD GetInState SYNC METHOD GetInBit SYNC METHOD GetOutBit METHOD Init METHOD SendMessage METHOD ReceiveMessage SYNC METHOD Command METHOD Reply && HIDDEN * These methods use :Command() and hence don't need the SYNC attribute METHOD SetRoleString METHOD GetRoleString METHOD Squawk METHOD SetHardwareInBitMask METHOD SetHardwareOutBitMask Using SYNC here is not necessary METHOD GetInCounter METHOD SetInCounter SYNC METHOD RegisterNotificationSink SYNC METHOD DeregisterNotificationSink METHOD ConnectTomRfDevice HIDDEN: CLASS METHOD FindDevicePort METHOD ReadACharOrWaitALittle METHOD Listener INLINE METHOD EventsWaiting RETURN .NOT. ::eventQueue:Empty() METHOD SetEventFilterBlock ENDCLASS --- snap --- | |
Osvaldo Ramirez | Re: Michael's Xbase++ OOP Survival Manual, Part III on Thu, 06 Nov 2008 20:10:31 -0700 Michael Hoffmann wrote: > > Thanks. I'm looking forward to seeing you again, soon! > I hope to ... Some times is good to see others areas like communications device. Well, a client of mine, want to control cash register via HTTP, so far so good, So a friend of mine, are designer a electronic board to control an 'servomotor' using this Web server ADAM-6052, this kind of device has inside an web server that are controled all pins. http://www.advantech.com/products/16-ch-Source-type-Isolated-Digital-I-O-Module/mod_1-2MLEAP.aspx So, We can open, close, know some status or send a pulse over some ping via remote using http or tcp. If you has time, let me know your point of view about adam-6502 Thas was the reason because I asked you. Thanks a lot and Best Regards Osvaldo Ramirez | |
Michael Hoffmann | Re: Michael's Xbase++ OOP Survival Manual, Part III on Fri, 07 Nov 2008 07:43:06 +0100 Hello Osvaldo, before developing Tom we checked out the devices on the market if they fitted our needs. One of them was a similar Advantech I/O device and it even made it into some of our productive software. Their devices seem to be well manufactured and so far we didn't have any trouble with it. Unfortunatly it was not the ultimate solution for us because it does not have an event queue (which the sales guy told us it should have) with time stamped events. So, when your computer has some of its "silent moments" (blocked for some seconds due to some network I/O), your software wouldn't be able to even pick up changes on the I/O ports. Tom buffers all events. For your problem the Adam-6052 should work perfectly, however I must admit that opening and closing a cash register via TCP/IP over a network is a bit of overkill and might even become a security leak. The controllable cash registers I have seen so far are spring loaded and the software just releases a drawer lock which allows the spring to push the drawer open. This lock release action seems to be triggered by a signal change on one pin of a serial port. That should be a lot cheaper than the Adam 6052 + electronics to control a servo motor. Best regards, Michael ------------------------------ www.xcockpit.com ------------------------------ |