DSP Robotics Support

Included is a code file for my machine controller that will use 2 Phidgets 1063 stepper motor controllers and the Phidgets 1019 8/8/8 I/O board with USB hub.

My question involves how to use Ruby with this controller. I have separate test control panels for the I/O board and stepper motors 1 and 2 already written and working fine (see the attached file). My next step is to write Ruby code that will interact with the I/O panel and steppers 1 and 2 and operate them in a complicated sequential manner. So the Ruby code needs to sense inputs and control outputs on the I/O board and move stepper motors 1 and 2. If you look at the I/O board schematic you can see I already attached a Ruby component that connects to the inputs and outputs on the I/O board. Can I add Ruby components to the Stepper 1 and Stepper 2 schematics and have the 3 Ruby windows communicate with each other? Or does there need to be only 1 Ruby window that connects to the 3 boards? Please advise as it is not so clear how to proceed.

I added an image file for the controller.

You can have as many Ruby components as you like.

They can only communicate with each other if you connect them.

Also your selector buttons are a bit over complicated, here is a better way:

Thanks for the tip on Ruby and providing a less complicated menu selector. I agree my menu selector was overly complicated and getting more so as I added more menu items!

DSP wrote:You can have as many Ruby components as you like.

They can only communicate with each other if you connect them.

Hmm..
I thought I read about global vars between not only ruby code moduals, but all instances of your program too.. ?

VPDannyMan wrote:I thought I read about global vars between not only ruby code moduals, but all instances of your program too.. ?

That's right, global and class variables are all shared across modules and instances. But without some fiddling with object bindings, changing their values won't trigger new events in other modules - the new values will just sit there waiting to be read by something. Maybe that's what DSP was getting at when he said 'not communicating' - you need the link there to trigger something to happen at the other end.

OK so globals are useless as a communication/Interop mechanism would you say?

VPDannyMan wrote:OK so globals are useless as a communication/Interop mechanism would you say?

Not necessarily - I've been making some use of them for the Debugger tool that I'm working on. And there are ways to trigger events between Rubies - but sometimes with strange side effects.
Here's a simple example...
Put two Ruby primitives into a schematic and connect a text readout to the standard default string output on each of them.
In the first one make a global variable that refers to the RubyEdit instance pointer...

Code: Select all

$THIS_RUBY = @this

In the second Ruby instance, now call any of the RubyEdit methods, giving the Global reference as an explicit receiver...

Code: Select all

$THIS_RUBY.output 0,"Hello"

...and the text magically appears at the output of the first Ruby instance.
You can achieve similar things in other ways; for example, passing around blocks of code as "Proc" objects that store the context in which the code block was declared. New Classes and Modules are also global, so it's also possible to define Module and Class methods that can be called from anywhere, but produce output in a particular place...

Code: Select all

# RUBY 1
$THIS_RUBY = @this
module Foo
def self.output(value)
$THIS_RUBY.output 0,value,0
end
end

Code: Select all

# RUBY 2
Foo::output("Hello")

However, here's the weird thing that I've noticed...
The easiest way to trigger events in another Ruby is by calling the input and output methods. But each Ruby instance also has it's own instance of the clock that is used for event scheduling.
When you call an event between different Ruby instances, the difference between the clocks messes with the timing of the triggers - they seem to get 'jet lagged' by the time difference between the two Ruby instance start times.
If you want the event to happen right now, you can seemingly get around this by setting the 'time' argument of the method to zero...
$THIS_RUBY.output 0,"hello",0
...but if you want to schedule an event for later, I've yet to find a reliable way to compensate for the time differences.

I've certainly had some useful results working with this stuff, but you do have to be very careful. Using objects with global scope, and the 'persistence' of values and definitions, makes for lots of opportunity for unexpected results when a variable is being targetted from all angles. This is more critical, I think, for those of us making VST plugins, as it is very common to run several instances of the same one within a music project - but they will are share the same set of global variables, classes and modules. I'm looking into this at the moment to see if there some way that instances could be indexed- but nothing reliable so far.

One other little tip - when working with globals that might be set from several places, the 'OR equals' method is very handy...

Code: Select all

$MY_GLOBAL ||=  []  # Global 'Or equals' empty array
$MY_GLOBAL << This value  # New item into the array

The '||=' means "If this variable isn't set yet, use this value, otherwise keep the existing value". So in this case, the first time it is run, the global var' gets set to an empty array and a start value is fed in. Every other time it is called, a new value is added to the array without disturbing what is there already.

Hmm. I will be doing some playin around later I think..
Very interesting, thanks.