I am trying to controll a Marshall PZT Camera with a raspi over rs422 over VISCA protocol. I think i can use [comport] but i don't understand puredata (anymore).
In the camera manual it tells me to send a string of HEX numbers 8x 01 04 3F 02 01 FF but with comport i can send bytes as decimal numbers. I dont understand how to convert these.
Does anyone has experience or understands how to do this?

@Johnny-Mauser If it's just those 7 numbers you need to convert to decimal, why not just Google it? Or if you are on Windows 10, you can use the built-in calculator in programmer mode, select hex, type in the number, and read out the decimal representation.

@Johnny-Mauser The reverse is possible easily in Pd....... and what you need will be.... with some work.
No time today so someone will beat me to it.
Here is the reverse.... and [expr] or a lot of operators will get decimal from 8 byte Hex.....
It could be easiest to do the maths on the binary values.

This will help with understanding 4 and 8 byte Hex...... https://www.zytrax.com/tech/protocols/hex.html
David.

vanilla's native [f ] object will convert symbols with hex numbers to decimal for you. Example:

[symbol 0xff(
|
[f ]
|
[255\ <- this is a number atom

puuh, thank you all, i will try to see through all of this. The system is very hard to debug for, 'cause the Camera is either moving or not. And there are a few stepping stones on the way..

@alexandros Very good.....
So...... simple.....
David.
([f] converts from Pd 0.48 onwards.)

well, @whale-av, @alexandros, i thought that the conversion of [list fromsymbol] is what i need 'cause with print i get the bytes to send? I only understand half, so is it for you possible to follow what i mean:

[FF(
|
[list]
|
[list fromsymbol]

{bundle bytes and send to device}

@Johnny-Mauser Yes, I thought so at first.
But it returns the ASCII decimal values for example of the characters D and E separately...... list D E
What is needed is the decimal value of the 8-byte HEX DE.
There is no decimal ascii value for a character DE as the character does not exist.

It would be possible using [list fromsymbol] and some maths but it is complicated because when the list is split using [list split 1] the second outlet continues to output the remembered 2nd value (E) when there is no new value....... i.e. for decimal 0 to 15 (HEX 00 to 0F).
David.

The device manual demands this Hex numbers:
81 01 04 3F 02 01 FF
as far as i understand now this is the list i need to send:
129 1 4 63 2 1 255
i didn't find a universal solution in your answers, but followed this table, which also shows the bits and therefore i beginn to understand a little bit more..

If I understand what you say, your issue is that the "print" messege sent to [comport] translates values to ASCII, right? In that case, you can send raw bytes without the "print" message. Just send a list of values that you pass through the [f ] object and you should be fine.

@alexandros, no. I send the numbers directly allready now, like shown in the [comport] help patch. My camera is still not moving.

@Johnny-Mauser What about the serial port stuff like baud rate, start & stop bits, etc? Is that all set to what the camera expects? Do you have the right port #?

@Johnny-Mauser What @jameslo says and.....
So the first message.....81 01 04 3F 02 01 FF..... recall preset 3 on camera 1..... does preset 3 exist....... Is the camera set as camera 1?
Does an error message come back from the camera?
Have you thought of doing it over IP..... ethernet?
Does the camera have the firmware upgrade (around year 2019) that enables HEX commands?

But I wonder if a text string would in fact work........ [print 81 01 04 3F 02 01 FF( ....into comport.
...... and.... hard to find..... but do you have noise from a bad ground or a bad power supply?
RS422 is balanced, but if there is a lot of noise coming from the device balancing will not help.
David

Dear @jameslo and @whale-av! Thank you for looking into this. David you really did dig into this, thanks! I finaly had to finish the show without this raspi controller because i could not get it to work, and now i cant touch the cameras for a while. But i hope i have the chance to investigate again. Here are some answers to your questions for future reference meanwhile:
What about the serial port stuff like baud rate, start & stop bits, etc? Is that all set to what the camera expects? Do you have the right port #?
-> I really dont know. I have a similar Camera like this followed this manual for the rs422 commands and dont know what else it needs concerning start and stop bits.
The camera has to Interface for VISCA over IP unfortunatly.
Is the camera set as camera 1?
-> I think so, yes. I use this controller and it works.

• Does an error message come back from the camera?*
  -> i don't know. I dont know how to read whats coming back.
• Have you thought of doing it over IP..... ethernet?*
  -> yes that would be the best, but i think my camera does not support that.
• Does the camera have the firmware upgrade (around year 2019) that enables HEX commands?*
  -> i think it should work with HEX since the controller is working fine.
  But I wonder if a text string would in fact work........ [print 81 01 04 3F 02 01 FF( ....into comport.
  -> I will try that, even though i have not the biggest hope for succes this way.
  do you have noise from a bad ground or a bad power supply?
  -> could be. But if i evaluate my knowledge so far, i think it is most likely a user error still. I will report here if i know more, or have more questions.

@Johnny-Mauser Do you have the Tx and Rx connections crossed over........ i.e. Tx from comport connected to Rx at camera?
Checksum seems irrelevant for VISCA.... so no need to go into that.
I see there is a baud rate physical switch on the camera...... 9600 or 38400...... make sure comport matches that.
Set comport with some messages i.e.

You could make a loopback plug for your rs422 socket and use a terminal, or Putty in windows, to see the messages actually being sent.
David.

This is a extented Ascii table http://www.nha.dk/hex.html