Make a Hex Cue

[luckydave]

I've been working with a few QLab users recently on sending hexadecimal codes to networked devices like matrix switchers and projectors, to control things like selecting a matrix input or closing a projector's shutter. QLab's Network cue sends OSC and ASCII over UDP, but it doesn't have support for hex codes or TCP at the moment. So we must turn to the Script cue.

I've attached a workspace file that has two script cues. The first creates script cues that use AppleScript's "do shell script" functionality to run a bash "echo" command to format text as hex codes, and pipes it to "nc" to send as either UDP or TCP to your IP address and port of choice. The second script cue is an example of what gets created, with all of the default choices.

When you run the first script cue, dialogs pop up asking for the command name, which becomes the cue's name, and a comment in the script, the new cue's number, the hex code, IP address and port, and protocol choice of UDP or TCP. If you find that you'll always use the same IP address and port, there are variable definitions at the top of the script where you can enter those. Just comment out the "display dialog" line of code that corresponds to that variable, and the dialog won't bother you, using the stored value. Two hyphens at the beginning of the relevant "display dialog" line will suffice.

Give it a hotkey, and then you can select the cue that the new script should follow, hit the hotkey, enter relevant values, and your script cue shows up in place.

At the moment, I don't have access to a networked device that responds to hex codes, so I haven't been able to test this for myself. However, I have gotten enthusiastic reports of success from one QLab user with a Kramer matrix that uses UDP. It still needs to be tested for TCP, but I don't know of a reason it wouldn't work.

If you use this and have success, please let me know how you used it, and your results. If you use this and don't have success, please let me know how you used it, and your results, and I'll try to resolve the problem as I have time. If you use this and fix a problem yourself, I'd love to know what was necessary to make it work in your situation.

--

luckydave

[luckydave]

The code in question:

-- Use the following variable definitions to automate any of the dialogs. Just give it a value, and comment out the dialog below to disable it. For example, set IPAddress to "192.168.1.251" if you'll always use that value.

set commandName to "" -- Any text will suffice: it's used for a comment in code, as well as the new cue's name

set newCueNumber to "" -- This will be unique each time. If you don't want a number, just comment out the dialog below and leave this empty.

set hexCode to "" -- Space-delimited hex codes.

set IPAddress to "" -- The device's IP address, e.g. 192.168.1.251

set networkPort to "" -- The device's receiving network port e.g. 50000

set protocolChoice to "" -- UDP if you need it, leave it empty for TCP.

set commandName to text returned of (display dialog "Command Name:" default answer "Kramer In 1" with title "Command Name" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set newCueNumber to text returned of (display dialog "New Cue Number:" default answer "1001" with title "Cue Number" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set hexCode to text returned of (display dialog "Hex Code (ensure a space character between each hex byte):" default answer "01 82 81 81" with title "Hex Code" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set IPAddress to text returned of (display dialog "IP Address:" default answer "192.168.1.185" with title "IP Address" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set networkPort to text returned of (display dialog "Network Port:" default answer "50000" with title "Network Port" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set protocolChoice to button returned of (display dialog "TCP or UDP?" with title "TCP or UDP?" with icon 1 buttons {"Cancel", "TCP", "UDP"} default button "UDP" cancel button "Cancel")

-- Use nc's default TCP, or specify UDP?

set transportProtocol to ""

if protocolChoice is "UDP" then

set transportProtocol to "-u "

end if

-- parse space-delimited list of hex codes to a list called eachHexByte

set oldTIDs to AppleScript's text item delimiters

set newTIDs to {" "}

set AppleScript's text item delimiters to newTIDs

set eachHexByte to every text item of hexCode

set AppleScript's text item delimiters to oldTIDs

-- make hex codes echo-able

set hexCodeString to ""

repeat with eachByte from 1 to (count eachHexByte)

set thisByte to item eachByte of eachHexByte

-- strip hextra code (0x or $ or however the manufacturer spells it out)

set thisByteCount to count (characters of thisByte)

if thisByteCount is greater than 2 then

set thisByte to characters (thisByteCount - 1) thru thisByteCount of thisByte

end if

set hexCodeString to hexCodeString & "\\\\x" & thisByte

end repeat

-- put together the shell script

set shellScript to "echo -ne '" & hexCodeString & "'|nc " & transportProtocol & IPAddress & " " & networkPort & " > /dev/null 2>&1 &"

-- put together the source of the script cue

set scriptSource to "-- " & commandName & return & "try" & return & "do shell script " & "\"" & shellScript & "\"" & return & "end try"

-- make a new script cue using the script source

tell application id "com.figure53.qlab.4" to tell front workspace

make type "Script"

set theScriptCue to (first item of (selected as list))

set script source of theScriptCue to scriptSource

compile theScriptCue

set q name of theScriptCue to commandName

set q number of theScriptCue to newCueNumber

end tell

[Ron Peer]

You sir, just made my day!

.Thank you so much for this script, I've had allot of hassle getting those X20 units, christie shutters, Pulse switchers many more getting triggered from Qlab.

Going to test it right away!

Thanks allot mate.

בתאריך יום חמישי, 5 באוקטובר 2017 בשעה 01:43:34 UTC+3, מאת luckydave:

[Ron Peer]

One quick question, how do you send NULL character?

בתאריך יום חמישי, 5 באוקטובר 2017 בשעה 01:43:34 UTC+3, מאת luckydave:

I've been working with a few QLab users recently on sending hexadecimal codes to networked devices like matrix switchers and projectors, to control things like selecting a matrix input or closing a projector's shutter. QLab's Network cue sends OSC and ASCII over UDP, but it doesn't have support for hex codes or TCP at the moment. So we must turn to the Script cue.

[luckydave]

As far as I'm aware, a hex null is just 00.

--

luckydave

[Gregg Carville]

First off, thank you for this - as it is something I have been looking at for a bit without luck.

I tried it with an NEC PX750U projector that I networked to no avail. 

I have been able to send Hex commands using Packet Sender with success to this projector.  Packet Sender doesn't support Apple Script (that I can figure out - I'm pretty new to this) and so doesn't look to be a long term solution.

I have had prior success with PJLink commands, but the commands only allow for the unit to "mute" which is not a full blackout.

Thank you,

Gregg

Here are the scripts:

-- Shutter Projector

try

do shell script "echo -ne '\\x02\\x16\\x00\\x00\\x00\\x18'|nc 192.168.0.10 7142 > /dev/null 2>&1 &"

end try

-- Open Projector

try

do shell script "echo -ne '\\x02\\x17\\x00\\x00\\x00\\x19'|nc 192.168.0.10 7142 > /dev/null 2>&1 &"

end try

[luckydave]

The scripts you've pasted in use TCP. Have you tried UDP?

--

luckydave

On October 5, 2017 at 10:35:56 AM, Gregg Carville (carville...@gmail.com) wrote:

I tried it with an NEC PX750U projector that I networked to no avail. 

[Gregg Carville]

Same results - here is that script.

I know the command is good as when I send it in PacketSender it works.

FYI PacketSender shows the ASCII as this: \02\16\00\00\00\18

When I try to send it UDP in PacketSender it does not work. If I send it TCP it does.

Gregg

-- Close UDP

try

do shell script "echo -ne '\\x02\\x16\\x00\\x00\\x00\\x18'|nc -u 192.168.0.10 7142 > /dev/null 2>&1 &"

end try

[Gregg Carville]

For what it is worth, it is not coming back with a script error or such. Just nothing happens.

Thanks, Gregg

[luckydave]

Hi Gregg.

If you paste the following into Terminal and press [enter], what result do you get?

echo -ne '\\x02\\x16\\x00\\x00\\x00\\x18'|nc -u 192.168.0.10 7142

--

luckydave

[luckydave]

Sorry, this:

echo -ne '\\x02\\x16\\x00\\x00\\x00\\x18'|nc 192.168.0.10 7142

--

luckydave

[Gregg Carville]

Nada. I test it with PacketSender and that works fine. But just putting the command in Terminal does not work. I tried the UDP too just in case.

I attached a screen shot just in case there is something obvious I missed. I have also tried it on other computers just to see if there was something goofy with this particular one.

Thanks, Gregg

[Gregg Carville]

Nada. I test it with PacketSender and that works fine. But just putting the command in Terminal does not work. I tried the UDP too just in case.

I attached a screen shot just in case there is something obvious I missed. I have also tried it on other computers just to see if there was something goofy with this particular one.

Thanks, Gregg

On Thursday, October 5, 2017 at 5:40:54 PM UTC-4, luckydave wrote:

[Rich Walsh]

I haven’t been following this thread in depth, but three things strike me:

1. There doesn’t seem to be anything fancy about this “hex” string to me: it just looks like an ASCII string “\\x02\\x16\\x00\\x00\\x00\\x18”; perhaps the intention is to use \\ not inside ' ' so as to comment out \ – so the string is sent as "\x02\x16\x00\x00\x00\x18”? Wireshark is capturing precisely the ASCII contained within the ' ' – with x & \\.
2. From your screenshot it looks like your device is expecting "\02\16\00\00\00\18” – no x characters? Try echo -n '\02\16\00\00\00\18’ | nc 192.168.0.10 7142.
3. I can’t find -e as a flag for echo in its man page; why’s it there? Also, do you need a w 0 flag for nc to prevent timeout?

In summary, try this:

echo -n '\02\16\00\00\00\18' | nc -u -w 0 192.168.0.10 7142

Rich

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/523698e3-f2ee-4e28-873b-09deee406c87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<gcscreen.tiff>

[luckydave]

https://linux.die.net/man/1/echo

The -e argument enables interpretation of backslash escape codes.

The \xHH sequence tells echo to interpret HH as a byte with hex value HH. I got the double-backslash "\\x" from a customer who reported that string worked for him, so I've been working from there as a starting point. I'd expect it should work with a single backslash, and the double backslash may be confusing things, as that should translate to "backslash", rather than "this is hex". So in the real world, this is the command that I'd expect to work for TCP hex:

echo -ne '\x02\x16\x00\x00\x00\x18'|nc 192.168.0.10 7142

And with timeout of 0:

echo -ne '\x02\x16\x00\x00\x00\x18'|nc -w 0 192.168.0.10 7142

The only reason I've been working with double-backslash is that it was reported to work. This was UDP, and it was specific hardware, so it could be that this hardware is more forgiving in what it expects to receive. Give a try with the above from the command line, and if either of them works, I can update the script. If it works for your setup, it should work fine for other UDP setups, as it appears to be more accurate.

Rich - I'm mostly ignorant on the "with timeout" option for nc. Would that eliminate the need for redirecting stderr and stdout that I have in my script? Without the redirection, the script waits for feedback, so the script cue never stops running. Do you know if the timeout would resolve that?

(I freaking love this group!)

--

luckydave

[Rich Walsh]

I’ll think a bit harder later, but https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/echo.1.html (and “man echo” locally) suggest that the MacOS implementation of echo doesn’t do all that fancy stuff…

As for w/o timeout I think that should cause the shell script to fire off without waiting for an answer so the script can move along – but I’ll need to go digging into your code to understand how you’re using it…

Rich

-- 
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CANrzNvyvTezsi7MVNRZUHLdka5%2B_G7ncpQOxDWA56vGEx0ZKZg%40mail.gmail.com.

[luckydave]

So I haven't ever really understood it because my UNIX education was a long time ago and all from a book that assumed I knew more than I knew when I read it 25 years ago. I'm rusty is what I'm saying. But as far as I can tell, the "man" command doesn't always give the correct manual page because it's giving the "sh" shell's man page, and the default shell on macOS is "bash". To get the details for the bash manpage, type "help echo" rather than "man echo", or search online for bash manpages. That's why I sent the link to a Linux manpage, rather than Apple's. As with most things on the shell, it's confusing. But I do believe the "-e" flag works to enable interpretation of backslash escapes in our case.

I just tested with "-w 0", and the timeout does not trick AppleScript into deciding not to wait for feedback, so the redirect is still necessary.

I also realized the purpose of the double-backslashes. It's to get AppleScript to allow a backslash in the first place. It's an escape for an escape. We have to escape the backslash for AppleScript in order to pass it along to the shell so echo can treat it like an escape. I wonder if there's a better way to build this...

--

luckydave

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/0AC08B3E-32AE-4C60-AD98-EF544C4E91DD%40mac.com.

[Gregg Carville]

Nope, that did not work.

[Gregg Carville]

No luck with either of those...

It may be something particular about my setup that I am missing....

Thanks for the help. 

[Rich Walsh]

I get this:

eclipse:~ rich$ help echo
echo: echo [-neE] [arg ...]
    Output the ARGs.  If -n is specified, the trailing newline is
    suppressed.  If the -e option is given, interpretation of the
    following backslash-escaped characters is turned on:
     \a alert (bell)
     \b backspace
     \c suppress trailing newline
     \E escape character
     \f form feed
     \n new line
     \r carriage return
     \t horizontal tab
     \v vertical tab
     \\ backslash
     \0nnn the character whose ASCII code is NNN (octal).  NNN can be
     0 to 3 octal digits
    
    You can explicitly turn off the interpretation of the above characters
    with the -E option.

I don’t see \x in that list, and using \t as an example I see no difference in Wireshark’s interpretation of the data between -e set and -e not set… Indeed, even just doing “echo -e \t” echoes “t” not “tab” to the screen. If I use /bin/echo then it even echoes the -e!

In my untrained fumblings around the Terminal I have frequently found that the MacOS version of some Linux command I’ve found on the web doesn’t do exactly the same thing…

Has anyone actually sniffed the packets and confirmed it’s real hex bytes coming out?

I wonder if this form works:

echo 41 | xxd -r -p | nc -u -w 0 127.0.0.1 53535

This appears to generate a UDP packet containing hex data “41” (= decimal 65 = ASCII code for “A”). I don’t really know much about this, but I’m assuming that what we’re trying to achieve with a raw hex packet would be indistinguishable from an ASCII packet with the hex bytes values mapped to the corresponding ASCII characters?

Rich

[Rich Walsh]

How about:

echo 021600000018 | xxd -r -p | nc -u -w 0 192.168.0.10 7142

Rich

[Rich Walsh]

So. I did a bit of testing with the original script and QLab and discovered that:

do shell script "echo '\\x41'” ––> “A”

echo '\x41’ ––> “\x41”

do shell script "echo -e '\\x41'" ––> "-e A”

echo -e '\x41’ ––> “A”

So, confusingly the -e flag is echoed if set in AS, and works for \x in Terminal even though it’s not listed. Everything I said below is wrong as I’d missed that you need to encapsulate in ''.

Short version: if the script makes this form then what comes out in Wireshark is the raw hex bytes:

do shell script "echo '\\x01\\x82\\x81\\x81' | nc -u -w 0 127.0.0.1 50000"

Rich

[Rich Walsh]

Or:

echo -e '\x02\x16\x00\x00\x00\x18\c' | nc -w 0 192.168.0.10 7142

Figured out you need the final \c to get rid of the 0a/LF sent at the end…

Rich

[Rich Walsh]

Finally, an alternative version of luckydave's script with some mods:

-- Use the following variable definitions to automate any of the dialogs. Just give it a value, and comment out the dialog below to disable it. For example, set IPAddress to "192.168.1.251" if you'll always use that value.

set commandName to "" -- Any text will suffice: it's used for a comment in code, as well as the new cue's name

set newCueNumber to "" -- This will be unique each time. If you don't want a number, just comment out the dialog below and leave this empty.

set hexCode to "" -- Space-delimited hex codes.

set IPAddress to "" -- The device's IP address, e.g. 192.168.1.251

set networkPort to "" -- The device's receiving network port e.g. 50000

set protocolChoice to "" -- UDP if you need it, leave it empty for TCP.

set commandName to text returned of (display dialog "Command Name:" default answer "Kramer In 1" with title "Command Name" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set newCueNumber to text returned of (display dialog "New Cue Number:" default answer "1001" with title "Cue Number" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set hexCode to text returned of (display dialog "Hex Code (ensure a space character between each hex byte):" default answer "01 82 81 81" with title "Hex Code" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set IPAddress to text returned of (display dialog "IP Address:" default answer "192.168.1.185" with title "IP Address" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set networkPort to text returned of (display dialog "Network Port:" default answer "50000" with title "Network Port" with icon 1 buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")

set protocolChoice to button returned of (display dialog "TCP or UDP?" with title "TCP or UDP?" with icon 1 buttons {"Cancel", "TCP", "UDP"} default button "UDP" cancel button "Cancel")

(* MOD START *)

-- Use nc's default TCP, or specify UDP?

if protocolChoice is "UDP" then

set transportProtocol to "-u "

else

set transportProtocol to ""

end if

-- make echo string from hex code input ### NO ERROR TRAPPING HERE IF hexCode WRONG FORMAT ###

set hexBytes to {"'"}

set currentTIDs to AppleScript's text item delimiters

set AppleScript's text item delimiters to space

repeat with eachWord in text items of hexCode -- Space delimited

set end of hexBytes to text -2 thru -1 of eachWord -- Take last 2 characters even if just 2

end repeat

set AppleScript's text item delimiters to "\\\\x" -- Need \\ in final output for Script Cue, but each \ needs a \ to escape it here, so \\\\!

set echoString to (hexBytes as text) & "\\\\c'" -- Need this to prevent LF at end of echo

set AppleScript's text item delimiters to currentTIDs

-- put together the shell script

set shellScript to "echo " & echoString & " | nc " & transportProtocol & "-w 0 " & IPAddress & " " & networkPort

(* MOD END *)

-- put together the source of the script cue

set scriptSource to "-- " & commandName & return & "try" & return & "do shell script " & "\"" & shellScript & "\"" & return & "end try"

-- make a new script cue using the script source

tell application id "com.figure53.qlab.4" to tell front workspace

make type "Script"

set theScriptCue to (first item of (selected as list))

set script source of theScriptCue to scriptSource

compile theScriptCue

set q name of theScriptCue to commandName

set q number of theScriptCue to newCueNumber

end tell

It seems to generate cues that spit out what I'm expecting in Wireshark…

Rich

[luckydave]

Thanks Rich for all the help there! I've edited the workspace to include the new and improved script, attached here. (You're thanked in comments as well, Rich!)

--

luckydave

[Gregg Carville]

Thank you both, unfortunately I can not get it to work in my setup. Packet Sender continues to work, but putting that script through (either in Qlab or in Terminal) gets nothing.

I appreciate the assistance, The only thing I can think of is that Packet Sender receives info back from the projector, and this is a needed step that Qlab or Terminal can't or won't do.

My next plan is to play with RS232 and Cool Term. 

[Rich Walsh]

The key thing that's different is that you're using TCP not UDP. If I use nc to open a port and listen on it, I can see several messages go back and forth to that port as the TCP connection is opened and then closed; I can clearly see the hex string sent in one of the packets in the middle. Without a port open and listening, the shell command fails with an error in AppleScript, but fails silently in Terminal.

Are you able to use something like Wireshark to confirm that the TCP packets being sent by QLab are the same as those sent by Packet Sender? I can't see why this shouldn't work in principal…

Rich

[Gregg Carville]

When I tried UDP in Packet Sender it failed. I tried both in Qlab today to no avail. 

I will look at Wireshark and see what I can figure out. I've not tried that before. I have time on Thursday for another crack at it.

Thanks, Gregg

--

Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
---

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/T_2lb9rPiO8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/C45E37FA-2D43-4032-922E-F2740E779002%40mac.com.

For more options, visit https://groups.google.com/d/optout.

<Screen Shot 2017-10-10 at 23.00.18.pdf>

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
---

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/T_2lb9rPiO8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/C45E37FA-2D43-4032-922E-F2740E779002%40mac.com.

[Gregg Carville]

Well this is interesting, not that I truly understand all of it.

I captured the transmission on Wireshark. When I use Packet Sender it has a Retransmission and about 4 other steps that are not seen when I use the Qlab script. I've attached screen shots.

The one thing that is the same is the last Hex packet are the same.

Any thoughts or guidance? Thank you, Gregg

[Gregg Carville]

I sent two pictures of the same thing. Here is the q lab grab.

[Rich Walsh]

It’s a bit out of my expertise too, but there isn’t a packet in the QLab grab that has a data length of 6: the closest to what I think is the actual “message” is the 4th packet, which only has a length of 5. I’d have a look at that packet and compare it with the one you’ve highlighted in the other screenshot – for some reason QLab isn’t sending all 6 bytes you need…

Rich

[Gregg Carville]

I decided to throw some more time at this and I have found a problem.  

In the packet that sends the Hex data via PacketSender, line 040 of the 5th transmission line [PSH ACK] shows the Hex data is being sent on the left hand side. on the right it lines up with some .....

In the packet that sends the data via Terminal, line 040 of the 6th transmission line [PSH ACK] shows that the hex data is not being sent but rather being translated into other hex data?

So it isn't sending the data as Hex is what I think I am seeing.

Any thoughts?

[Rich Walsh]

You should stick to testing with QLab as what you’ve done by switching to Terminal is got caught up in a separate issue: the syntax is different in Terminal to that in “do shell script”, as I’ve said before.

It looks like you’ve done this in Terminal:

echo '\\x02\\x16\\x00\\x00\\x00\\x18\\c’ | nc -w 0 10.116.28.141 7142 

If you look at the text interpretation of the message in the third column block you can see that it has echoed precisely the text string you entered to the TCP packet. You can also see that the TCP packet has 34 bytes of data, not 6.

Without the -e flag you have not asked echo to convert to hex. In Terminal you need to use this form (I posted exactly this – with a different IP address – a few steps back in the thread):

echo -e '\x02\x16\x00\x00\x00\x18\c’ | nc -w 0 10.116.28.141 7142

However, this doesn’t actually troubleshoot the problem you’d highlighted in your previous Wireshark screenshots: QLab was sending only 5 bytes of data, not 6. What you need to do is check that…

What was the script in QLab that generated the 5-byte message before?

Rich

[Gregg Carville]

Ok, I got confused and thought the script was talking through Terminal, so I was testing that. (Theater just got power back since Monday, so we've been literally dark for a bit...)

Even sending 6 bytes the message doesn't make it from Q Lab. (I'm using the latest file in this thread to send the message.)

From Q Lab I see 9 lines in WireShark versus 11 in PacketSender. 

QLab is sending from port 51134 and PS from 50989

PS does a secondary transmission (line 5 - highlighted in the screenshot) and there is an acknowledge from the projector (Line 6) that isn't there in the Qlab script.

FYI the Q Lab script is this:

-- Close Shutter

try

do shell script "echo '\\x02\\x16\\x00\\x00\\x00\\x18\\c' | nc -w 0 10.116.28.141 7142"

end try

For kicks I tried the echo with the -e in terminal and got nothing.

Admittedly I'm beyond my knowledge here. 

Thank you,

Gregg

[Rich Walsh]

So it looks like the projector doesn’t get the message the first time it’s sent; PacketSender is waiting for an ACK, so resends the message when it doesn’t get one – but nc isn’t waiting for acknowledgement so doesn’t send the message again. Possibly.

I don’t know how you change the TCP Retransmission timeout in netcat so that it waits for confirmation of receipt before closing the connection. Maybe try taking the “-w 0” bit out? Perhaps that bit only works for UDP?

Rich

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
---

You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/f3ce67df-0cce-4370-9324-cde258ab65d1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<Qlab_11_1_17_Close.jpeg><PS_11_1_17_Close.jpeg>

[Gregg Carville]

So I played with that, no luck. In the end I used OSC control to run a couple of subs on an Ion with a DMX paddle on it. Not elegant but it works and it has controllable timing.

I wonder what it would take for the Packet Sender programmer to add apple script support. He says he is up for customization. Not sure how much effort it is worth.

Thank you for your help,

Gregg

[Steve Swift]

Is it still the case that QLab network cues can’t send hexcodes, and this script from luckydave is the best approach currently?

I’m trying to send a hex string to a digital clock, and I have it working on the command line, but haven’t gotten the UDP message to work from QLab yet.

If the script method is the best approach, is there a way for the script to get use it’s q name as a variable? I’d like to create script cues where I can put the time “11:59” as the q name, and have the script read that name and use it in the script. Otherwise, I think I’m left hardcoding the values into each script. If someone has an idea how to avoid hardcoding, that would be great.

Thanks,

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/9c638b04-1092-46c5-b69f-e619943f2295%40googlegroups.com.

[Steve Sweeney]

THANK YOU LUCKYDAVE AND RICH WALSH for THIS CODE!!!!

After 16hrs of stressing out over this I now can use my SONY SRG-360SHE Cameras and QLAB to control them. This is a huge relief.

Special Shout out to Sony and DAN NAGLE at PacketSender for helping as well.

Really Appreciate this Guys!

Steve