VC-C4 RS232 camera control

vvvv beta general
1

I migrated out of my old thread now that I have gotten somewhere. Link

As far as I can tell it should work. At least a little.
I have learned many ways how not to make it work.

This was the best way I could make it considering I had to learn as I went. The way to handle the queue is in my eye ugly and inefficient but I don’t know how else to insert something into a queue when they are banged at the same time.

So if you guys can have a look at it, laugh for a while, and then maybe point me in the right direction. Or even help me.

It would be nice having one control module for every camera but I just didn’t know how it would work on the same bus. So I made one for the two cameras we have.

What I need to control is:
Pan & tilt, Pulling the value from the max/min values from the camera would be nice but at the moment choosing them manually is fine.
Color, Manual color balance.
One push AF, making the camera focus like a regular camera.
Manual focus, Would be nice to control it manually but it is not a priority.
Auto focus, choosing this mode would be nice.
AGC Gain, exposure compensation.
Zoom, Simple zoom as ar as I can tell.

Connecting it, On/Off, setting pedistal or inverted mode, resetting the unit etc. All those functions are needed but usually run once every time.

Seeing any errors returned and acting properly at them.
As it is now it should move to the next command in the queue if it receives an OK from the camera.

I have no idea how to implement it all. I know the most basic things can be done but it quickly becomes too complicated for me. Still new to vvvv.

VC-C4 (Device).v4p (98.1 kB)

2

three design tips for cleaning up your patch

(1) create a MakeViscaCommand subpatch for generating the command strings with the Map/Frac/Spellvalue/Pad stuff out of some parameters. then use this subpatch multiple times

(2) setup this subpatch that it will output the command strings when the patch gets initialized or when the input value gets changed. in all other conditions, just output an empty string.

(3) then you can just add all strings of all commands together, and send them to the RS232 simple if this compound command is not empty. this will eliminate most of your switch and OR nodes.

regarding the queuing:

i didnt test or check you patch with Counter and Queue - it may well work, but i somehow dont get how it would work efficiently.

I would go for a FrameDelay loop which implements a FIFO:

close the loop with two Switches -

one switches between the cycling value and the cycling value with the new incoming commands appeneded at the end.

the other switches between the cycling value and the cycling value with the first slice removed. (the first slice will then go to the RS232.

bang the first switch whenever there is a new message; bang the second whenever there is an OK received.

if you get this running you have mastered one of vvvvs most powerful concepts.

3

“(1) create a MakeViscaCommand subpatch for generating the command strings with the Map/Frac/Spellvalue/Pad stuff out of some parameters. then use this subpatch multiple times”

Ill try to shrink it down that way. Should be easy when I know what to throw away in my current patch.

“(2) setup this subpatch that it will output the command strings when the patch gets initialized or when the input value gets changed. in all other conditions, just output an empty string.”

The output to be sent through RS232 should be banged as soon as there is a change?
If the bus is stuck sending out other things in the meantime would it still mean I get the latest data available?

(3) then you can just add all strings of all commands together, and send them to the RS232 simple if this compound command is not empty. this will eliminate most of your switch and OR nodes.

Do you mean sending multiple commands together at the same time as a long string?
Would that work if the camera sends answers back?

regarding the queuing:

i didnt test or check you patch with Counter and Queue - it may well work, but i somehow dont get how it would work efficiently.

I would go for a FrameDelay loop which implements a FIFO:

It it definitely not effective. It takes a maximym of 10 cycles to pull all the toggled values to insert them into the queue in case they get banged at the same time.

How can I handle a input pin, for example Pan/Tilt that might always be changing at times. Like a constant Pan from one pos to another?

I am a little unclear what you mean by “FrameDelay loop”

close the loop with two Switches -

one switches between the cycling value and the cycling value with the new incoming commands appeneded at the end.

the other switches between the cycling value and the cycling value with the first slice removed. (the first slice will then go to the RS232.

bang the first switch whenever there is a new message; bang the second whenever there is an OK received.

I don’t get it yet. I will read it a few more times and will probably figure it out. But at least things I figure out myself will stick.

if you get this running you have mastered one of vvvvs most powerful concepts.

Sounds nice. That means that if I get over this learning curve it will just get easier.

Thanks!

4

I would go for a FrameDelay loop which implements a FIFO.

I am a little unclear what you mean by “FrameDelay loop”

Have a look at ampops Queue Advanced Module. I think it does what Oschatz suggested.