The not documentary function

Yuriy

The not documentary function: translate_device(vdvDev1, vdvDev2).
What it does?

Joe Hebert

translate_device() is not a standard Netlinx function (unless it's some sort of DUET or VA thing) so I don't think anyone can tell you what it does without seeing the source code for the function.

Yuriy

Why this code is compiled!?

PROGRAM_NAME='test'

DEFINE_DEVICE

vdvDev1 = 33001:1:0
vdvDev2 = 33002:1:0

DEFINE_START

translate_device(vdvDev1, vdvDev2)

DEFINE_EVENT

DEFINE_PROGRAM

Joe Hebert

Good question. I wish I had a good answer. I searched my hard drive and did find that Program Files\Common Files\AMXShare\Com\nlc.dll has the text "translate_device" inside the file but as far as I know that's not a function we have access to. Maybe someone else will have a better answer.

alexanbo

I think I seem to remember it's something to do with Duet. It's used for feedback and basically when you turn on a channel on in device 2 it really turns on the channel in device 1. Likewise when you get a push on device 1, it shows up as a push on device 2.

DHawthorne

alexanbo wrote:

I think I seem to remember it's something to do with Duet. It's used for feedback and basically when you turn on a channel on in device 2 it really turns on the channel in device 1. Likewise when you get a push on device 1, it shows up as a push on device 2.

Something like a COMBINE then, without the intermediate virtual device?

alexanbo

Not really a combine because the push will only show up on device two and the feedback will only show up on device one.

Hedberg

Sort of like "redirect_string" only different?

Is translate_device a keyword in Duet? It doesn't seem to be in Netlinx.

Not too long ago there was a discussion about "redirect_string" which is supposed to make two devices echo all string info from each other. Supposedly it obviates the need to write string handlers to relay info between two devices (for example, when using a TCP/IP connection from a PC or RS232 to IP device) to program an XAP800 or Polycom conferencing mixer through the RS232 port).

I couldn't get it to work. Has anybody used redirect_string successfully? I had a discussion once with a very experienced AMX programmer who told me that, "of course, you can use redirect_string to do that," but I'm not sure whether he actually did it successfully or just surmised that it would work.

[Deleted User]

Redirect string has nothing to do with DUET. I think this has been used in the comm module for the old dms panels. Another virtual device was created in this module and the translate device command was used between the the virtual and the dynamic device.

rfmoyle

I'm not expert in this stuff, but I've seen it before. If you grab the module for the Denon 5800 from the InConcert section, you'll find the 'comm' (Denon_AVR5800.axs) is actually editable.The top line is:

MODULE_NAME='Denon_AVR5800'(DEV port, DEV vRcvr)

a little later on we have:

DEFINE_DEVICE
    vdRcvr = DYNAMIC_VIRTUAL_DEVICE

and a lttle later yet we have:

DEFINE_START
    translate_device(vRcvr, vdRcvr)

and the vRcvr is never referenced again, it's all stuff like this:

// Automatically send some feedback on power up
    send_string vdRcvr, "'POWER=', avrPowerState"
    send_string vdRcvr, "'MUTE=', avrMuteState"
    send_string vdRcvr, "'VOLUME=', itoa(avrVolume)"

which I believe is the module sending stuff back to the string event handlers. Is this enough context for someone to hazard an educated guess as to what is happening here?


regards,
Bob Moyle

HARMAN_icraigie

Hard to explain what exactly it does except that it breaks feedback loops. If you've used any of that old Landmark gear on a Netlinx system, those modules all use it - its what creates all the mystery virtual devices..

I use it in a module that bridges device comm modules (iPorts more often than not), to the serial ports of Global Cache controllers through the virtual device of the Global Cache comm module

JohnMichnr

OK - trying to remember last sumer - Pgm III went over the translate_device(vdvMain,vdvModule) My notes are sketchy, but basically it can break the loop when you send a string or a command to a device in a module. It also allows you to turn a channel on in a device, and it will not show as on until it is turned on in the module.

Translate_device goes in the Start section of the module, and "connects" a virtual device defined in the module definition, and another virtual defice (vdvModule) Anything done to vdvMain will happen on the vdvModule.

Here is a quick demo that they did in class. Pulsing a channel on the main virtual device does not show the channel active (on the main virtual device) until it is turned on via the module device 2 seconds later.

MODULE_NAME='magic mod test' (dev vdvMain, dev dvDev)
(***********************************************************)
(***********************************************************)

DEFINE_DEVICE
vdvModule = dynamic_virtual_device

DEFINE_START
translate_device(vdvMain, vdvModule)


(***********************************************************)
(*                THE EVENTS GO BELOW                      *)
(***********************************************************)
DEFINE_EVENT
channel_event[vdvModule,27]
{
	on:
	{
		wait 20
		{
			off[vdvModule,28]
			on[vdvModule,27]
		}
	}
	
}


channel_event[vdvModule,28]
{
	on:
	{
		wait 20
		{
			off[vdvModule,27]
			on[vdvModule,28]
		}
	}
	
}



(***********************************************************)
(*            THE ACTUAL PROGRAM GOES BELOW                *)
(***********************************************************)
DEFINE_PROGRAM

(***********************************************************)
(*                     END OF PROGRAM                      *)
(*        DO NOT PUT ANY CODE BELOW THIS COMMENT           *)
(***********************************************************)

I remember thinking - wow that is cool, when would I use that, and then forgetting all about it until reading this post.

AMXJeff

Yuriy wrote: »

The not documentary function: translate_device(vdvDev1, vdvDev2).
What it does?

Translate_Device has nothing to do with DUET. It was created for early AMX programmed modules.

In short, links the two virtual devices together allowing for them to act as one, stopping the "ECHO" effect of send_command and send_strings.

There is alot of caveots when it comes to using this keyword, I would stay away from it unless you completely understand its use and actions.

But the quick down and dirty explaination. "Twisted Voodoo Dolls!".

HARMAN_icraigie

AMXJeff wrote: »

But the quick down and dirty explaination. "Twisted Voodoo Dolls!".

It really is too bad [img][/img] is disabled...

HARMAN_rgelling

Translate Device

Agreed. It has nothing to do with Duet and has been around much longer than Duet. It has always been built into the NetLinx programming language and came about as the result of modules and using virtual devices to communicate with them. It was a way to get around the echo effect that Jeff talked about. It is not documented anywhere I know of. In fact, for a long time AMX did not even want anyone to be aware of this (early paranoia I think).

Unless you are a very experienced programmer and truly understand the nuances of programming modules and the interaction of modules with virtual devices and the main NetLinx code you should avoid this.

Also, on the redirect command. This has nothing to do with modules or Duet. It is a command to redirect serial data coming in on a port to go out a different port. So if you redirect serial port 1 to serial port 2 then any input from serial port 1 not only goes up to your program in a data_event but also goes out the other serial port. An example of this might two devices from the same manufacturer which connect via serial. However, you also need to see that serial data. This is a way of sniffing on that port and still having the data show up on the other device.

BCalderwood

Is that a warning or a temptation? Just kidding.

HARMAN_rgelling

If you are like me, a temptation.

There really is no harm in that command. It can't do anything wrong other than have more events show up. But once you go down that path it will open up all kinds of questions about the effects of the command and it does get complicated. However, I'm guessing there would lots of answers from the guys on this forum.

ericmedley

icraigie wrote: »

It really is too bad [img][/img] is disabled...

It now works like this...

this was the wonderful outcome of the 2009 Gator Bowl.

daveh

I'm pretty sure I tried REDIRECT_STRING with IP devices and it failed. I will give TRANSLATE_DEVICE a go.
I'm working on a module to get IP connections to largely self manage.

daveh

TRANSLATE_DEVICE didn't work quite how I thought it would
I string events weren't triggering right and the ONERROR event for the IP Port not being open when a string came through was also not triggered. Back to the drawing board!

mush

From an old AMX document 'NetLinx Module Interface Specification'

4. The NetLinx module must create a dynamic virtual device (keyword DYNAMIC_VIRTUAL_DEVICE) and translate (keyword TRANSLATE_DEVICE) between it and the virtual device defined by the glue code as the interface device. This will remove echoes the glue code would normally see by sending commands to and affecting channels on the virtual device.

Auser

mush wrote: »

From an old AMX document 'NetLinx Module Interface Specification'

Care sharing that document (or where I can find it)? I don't think I've ever come across it...

PhreaK

mush wrote: »

From an old AMX document 'NetLinx Module Interface Specification'

4. The NetLinx module must create a dynamic virtual device (keyword DYNAMIC_VIRTUAL_DEVICE) and translate (keyword TRANSLATE_DEVICE) between it and the virtual device defined by the glue code as the interface device. This will remove echoes the glue code would normally see by sending commands to and affecting channels on the virtual device.

Thank you, thank you, thank you, thank you... that is exactly what I needed for this.

mush

PhreaK wrote: »

Thank you, thank you, thank you, thank you... that is exactly what I needed for this.

No worries mate!

I never thought I'd see the day that I would be able to help Phreak!

P.S. Don't forget this is not supported (anymore?).

PhreaK

mush wrote: »

P.S. Don't forget this is not supported (anymore?).

Neither is wrapping a NetLinx module inside a Duet module

Not supported is just another way of saying fun to implement.

jjames

Just thought I'd let you know - there's also an 'untranslate_device' which takes one argument.

JasonS

TRANSLATE_DEVICE is awesome, I use it in every module I write. It allows you to send COMMANDS and STRINGS and Turn Channels ON and OFF inside a module with out retriggering the code inside the module. It makes writing modules easier and makes them much more functional. I write the UI into all of my comm modules, it makes it very easy to implement control of a device in the Main program.

DEFINE_EVENT

BUTTON_EVENT [dvTouch_Panel, 0]
{
    PUSH:
    {
        TO [vdvModule, Button.Input.Channel]
    }
}

DEFINE_PROGRAM

Wait 2
{
    FOR (nFeedback_Channel = 1; nFeedback_Channel <= 255; nFeedback_Channel++)
    {
        [dvTouch_Panel, nFeedback_Channel] = [vdvModule, nFeedback_Channel]
    }
}

a_riot42

JasonS wrote: »

TRANSLATE_DEVICE is awesome, I use it in every module I write. It allows you to send COMMANDS and STRINGS and Turn Channels ON and OFF inside a module with out retriggering the code inside the module.

By this you mean that you can do this in a module:

// inside module A
send_level vdvDev, 1, 50

and not trigger this event:

// inside module A
level_event[vdvDev, 1]
{
send_string dvDev, "'VOL=', itoa(level.value)"
}

while still triggering:

// inside main code
level_event[vdvDev, 1]
{
send_level dvTP, 1, itoa(level.value)"
}

in the main code?


This would get rid of the echo that occurs when updating a virtual's level in a module that has events listening on the same channel. That would be very useful.
Paul

HARMAN_icraigie

a_riot42 wrote: »

This would get rid of the echo that occurs when updating a virtual's level in a module that has events listening on the same channel. That would be very useful.
Paul

That's exactly what it does.

nicholasjames

"Module Virtual Devices"

Check out the release notes in the AMX-PI for Duet firmware build 316 (v3.00.316). "Module Virtual Devices". It's also listed (but not explained) on page 76 of the Visual Architect manual. Seems likes essentially the same thing.