Author Topic: GSD problem  (Read 6276 times)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« on: November 01, 2005, 03:47:16 pm »
I'm trying to integrate with Pluto a serial device with 14 digital IO channels (it's a Weeder board , see www.weedtech.com ).
The simplest way should be to create a GSD (Generic Serial Device) and to write some ruby snippets to manage what to send over rs232 to drive such board.

I've been told that this should be a very trivial task (no programming skill required, maybe a couple of hours job).
So you can immagine how ... ehm ... :oops: ... I feel now, because after a couple of days reading docs and making several attempts my board sadly refuses to work with pluto.

In the beginning I was thinking about a possible hw failure (maybe the device, maybe serial port) but some of the tests I've made are totally excluding this option.

So I will write here what I've made so far, hoping that some of you experienced guys may give me a hint.

The device is quite simple, there are channels from A to N that can be driven as input or output by sending/reading proper strings over serial line.
This kind of devices are stackable, so every command has to start with device ID (using letter from A to P and from a to p).

So a typical command to switch off channel A on device A will require sending the following string:
ALA (A=device, L=low, A=channel).

If I connect my weeder board on my pluto box serial port and from a text console I issue "echo ALA > /dev/ttyS0", I actually get that channel A is switched off. So serial port, serial driver, serial cable and external device are OK.

To make this working on pluto I've made the following:
    - created a device template (following this
http://plutohome.com/support/index.php?section=document&docID=113)
- defined a couple of commands (On_A and Off_A) just to test
- added Ruby Internal Commands (as per this doc http://plutohome.com/support/index.php?section=document&docID=206)
- defined proper serial parameters (dev/ttyS0, 9600 8N1)
- saved the new template
- added a child device to core (where my board is plugged in)
- on Wizard -> Devices - Generic Serial Devices I selected to edit Ruby Source Code
- in the box related to Off_A I added the code
Code: [Select]

conn_.Send("ALA\n");

- then I pushed Test Code to see if something happens
[/list]

Unfortunately nothing happens. No data are transferred to serial device, even after a quick router reload and a full reboot.
In the  log dir  there is no trace of new device log (it should be something like 38671_Generic_Serial_Device), and in pluto.log I could't find trace about something related to this.

I also added a Lighting scenario, with a button that should fire the command On_A, but also here no result.

Surely I'm missing something. Is there anyone that can help me to figure out what?

TIA
Marco

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #1 on: November 02, 2005, 08:29:10 am »
First of all verify if you have package for Generic_Serial_Device (it is not installed untill you add some device that specifically asks for it, it is configurable via DeviceTemplate page)
Code: [Select]
dpkg -l 'pluto-generic-serial-device'
If it's not installed try
Code: [Select]
apt-get install pluto-generic-serial-device pluto-libserial
Then quick reload DCERouter.
After that you should be able to see Generic_Serial_Device in the list of running processes and see the log file.

Next thing:
Every tyme you modify Ruby code, you have to Quick Reload the router.
I know it's very annoying but it's because of pluto_main cache.
So I don't think that "Test Code" will do anything.

We usually quick reload the router after every modification and send command from command line with /usr/pluto/bin/MessageSend utility.

Now about the device hierarchy:
Usually we create one Generic_Serial_Device for interface board which is actually plugged in your computer. The devices attached to it are under that device and DCE messages are forwarded to the parent.
Code: [Select]
+[CORE]
|  + ...
|  +[Weeder board]
|    - [Device1] (DeviceData : channel = A)
|    - [Device2] (DeviceData : channel = B)
|    ...

So you don't need to create a new command "ON_A". You can simply send "ON" command to Device1, the command will be forwarded to parent device which will handle it in "Process_Receive_Command_For_Child" where it looks at the DeviceData of the child to which command is addressed, takes channel from there, and sends apropriate command into serial port.

This way we don't need to create 2-3-4-5-...-N commands for each device attached to your computer.

Hope this will help you.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #2 on: November 05, 2005, 05:52:55 pm »
Hi torindan and thanks for reply

actually pluto-libserial was missing, so I installed it and now I can see device log.

Nevertheless there is a problem regarding serial port parameters handling.

In the device template I defined 3 parameters:

serial port
bitrate
paritybit/stopbit

By looking on the device log it sounds that only the first one is properly handled (serial port, that is set by default to /dev/ttyS0), while second and third are giving problems.

Here is what my log says

Code: [Select]


Generic_Serial_Device, v.2.0.0.32
Visit www.plutohome.com for source code and license information

10      11/05/05 13:02:51.812           Device: 38678 starting.  Connecting to: localhost
10      11/05/05 13:02:52.061           Connect OK
10      11/05/05 13:02:52.061           Device 38678 has commad line <Generic_Serial_Device>.
10      11/05/05 13:02:52.062           Adding device: 38678.
10      11/05/05 13:02:52.062           Fetching Ruby code from Infrared Plugin
10      11/05/05 13:02:52.187           Fetched 1 commands...
10      11/05/05 13:02:52.187           Ba>=udRate not specified or invalid, using default: 9600.
10      11/05/05 13:02:52.187           Using port ttyS0, at bps: 9600.
10      11/05/05 13:02:52.188           Using paritybit/stopbit: n/1.
01      11/05/05 13:02:52.188           ^[[31;1mParitybit/Stopbit n/1 NOT supported.^[[0m
10      11/05/05 13:02:52.188           Using Idle Delay: 2000.
10      11/05/05 13:02:52.188           Requesthandler 0x809bf68 (device: 38678) runThread now running
10      11/05/05 13:02:52.188           Loading generated code...
Starting Ruby...


Baud rate is set by default to 9600 and paritybit/stopbit is set to N/1, but it looks like pluto doesn't like it.

For paritybit/stopbit I've tried several formats (N1 N,1 ... also 8N1) but none works.

In this situation I'm able to send some data throug serial port, but most probably they are received as garbage by external serial device so no command is executed.

I've also a second question related to device hierarchy.

By using a GSD gateway and several children device I can simply switch on/off the child device and the command will be forwarded and executed by parent device.
In this way I can implement in my GSD gateway the Process_Receive_Command_For_Child function with some code like this (taken from another post of this forum):

Code: [Select]

if cmd.id_ == 192 #192 is ON
    id=device_.childdevices[cmd_.devidto_].devdata_[12]; #12 is port/channel
    conn_.Send(id+"ON COMMAND")
end


I guess that in the "id" variable there should be a kind of identifier that allow me to send the command to the proper channel.

I modify it this way
Code: [Select]

if cmd.id_ == 192 #192 is ON
    id=device_.childdevices[cmd_.devidto_].devdata_[12]
    if id==0
     conn_.Send("ALA")
    end
end


Basically I want to decode when a command from device 0 is fired, then I send proper command over serial.

I gave it a try but I couldn't have it working. I always get this error on log:
Code: [Select]

10      11/05/05 16:51:24.532           Got power command for Device: 38679
10      11/05/05 16:51:24.532           Using delay of: 0.
10      11/05/05 16:51:24.533           Device has no AV properties
10      11/05/05 16:51:24.544           AVMessageTranslator::Translate begin
10      11/05/05 16:51:24.544               Status : CMD=192, TP=0, TI=0
10      11/05/05 16:51:24.544           AVMessageTranslator::Translate end
10      11/05/05 16:51:24.544           Message processed by Translator.
10      11/05/05 16:51:24.562           Routing Message 192 to 38679...
10      11/05/05 16:51:24.562           Dispatching Message 192 to 38679...
10      11/05/05 16:51:24.562           Command will be handled in Parent device.
10      11/05/05 16:51:24.562           Routing message to device 38679.
10      11/05/05 16:51:24.562           Routing message to Ruby Interpreter...
10      11/05/05 16:51:24.562           handleMessage for child
Calling method cmd_ReceiveCommandForChild in class 3038912180 with 1 parameters
01      11/05/05 16:51:24.563           ^[[31;1mError while calling method: Cannot call class method: cmd_ReceiveCommandForChild
error: undefined method `childdevices' for #<Ruby_Generic_Serial_Device::RubyDeviceWrapper:0xb5221e14>, line: 6
backtrace:
        in: (eval): 6
        from (eval):6:in `cmd_ReceiveCommandForChild'
^[[0m    
01      11/05/05 16:51:44.094           ^[[31;1mRuby was unable to handle the command in reasonable amount of time^[[0m


Could you explain me a bit more?

TIA
Marco

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #3 on: November 07, 2005, 05:19:45 pm »
Hi,
First of all try childdevices_ (with underscore).
Don't ask me why..It was that way before I took the project.

The idea with ID is this way:
- you have 1 device plugged in your computer
- to that device several other are attached, every one with an ID (in a form or another)
- so when you send "ON" to one oh those devices the right one should be turned on
- if you want so turn them all ON then the best sollution is to implement ALL ON(#440) command directly in GSD device, instead of hacking by adding a device with id = 0 to handle all devices

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #4 on: November 07, 2005, 07:58:52 pm »
Hi torindan

I'll give a try with childdevices_  and will let you know.

Any hint about properly setting serial port parameters (baud rate, parity, stop bit) in order to be able to communicate properly with external device?

Currently I'm stuck with that ... I know that data are sent over serial but I'm also sure that are not received properly because of wrong parity/stopbit settings ...

TIA
MArco

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #5 on: November 08, 2005, 12:31:56 am »
Hi torindan

here follows an update related to my serial device implementation via GSD.

I was able to settle the issues related to ruby code. In the sample code there was a missing "underscore" and a misplaced one.

Just in case someone else happens to need it, the correct code is:

Code: [Select]

if cmd.id_ == 192 #192 is ON
    id=device_.childdevices_[cmd.devidto_].devdata_[12] #12 is port/channel
    conn_.Send(id +"ON COMMAND")
end


Now when I send an ON command to child device this is properly decoded by parent device and some data is sent over serial port.

I still have the problem that serial communication is not correctly set, so data are not understandable by externale serial device. For this I definitely need some help.

I noticed also another thing. In the device newlog file there is plenty of these messages:

Code: [Select]

10      11/07/05 23:04:36.440           handleMessage directly
10      11/07/05 23:04:36.440           Command 350 not supported.


These messages are continuosly appended to log file at a rate of roughly twice every second.
The only way to stop this behaviour is to reload router, but as soon as I send another ON command to child device the messages start again.

Is this behaviour normal (I guess it isn't ...) ?
Is there something wrong/missing in my ruby code that is causing such flood of error messages?

TIA
Marco

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #6 on: November 08, 2005, 09:32:52 am »
The only thing wrong in your code is that you didn't implement "Process Incomming Data" command (which has id 350). So interface is trying to send you some data, you don't receive it, but the data is still there and knocking at your door.

For all available commands look into Advanced->DCE->Commands.

To set baud rate use as settings "B9600", "B4800" or B+needed_speed
To set parity bit please use one of the constants "N81", "E81" or "081" (these are the values I found in the code)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #7 on: November 08, 2005, 10:21:20 am »
Hi torindan

thanks for your support. Now device is working as expected and log is not flooded anymore.

It is now only a matter to write some ruby code to make it general enough.

Now I can say that actually making a GSD working is really a couple of hours job ... once you have all the info :) ...


Just one more info : is the new device template that I created on my pluto box automatically addedd to your central template repository, or can I take my time and make all my trials (and errors) and decide in the end whether to commit it to central database or not?


Thanks again and regards
Marco

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
GSD problem
« Reply #8 on: November 08, 2005, 10:46:19 am »
Well teoretically there is a tool for synchronizing databases (but as far as i know for a regular user the tool works one way only :from pluto to user).
So don't worry take your time and make it work.

But I strongly recomand you to save from time to time the ruby code you create into some file (I usually save the line numbered part which starts with RCODE in log file).
This is because if we (or somebody else) add a device template with same ID as the one you created and sqlcvs is not smart enough to solve the conflict your template (and code you created) will be overwritten.

So If you want to contibute, just send me an email with as much datails as possible about the device and ruby code you created and we'll add it in main databes, so it will be available for all users.