STorM32 Scripts - Revision history

OlliW: /* Running a Pano Sequence */

2016-03-06T09:35:38Z

Running a Pano Sequence

← Older revision		Revision as of 11:35, 6 March 2016
Line 179:		Line 179:
	STOP		STOP

	The SETANGLEYAW_W command sets the yaw angle to ~~30°~~, and waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait ~~after~~ each shot, and the total yaw angle range which shall be covered. The DOPANO commands finally run the pano sequence. The first DOPANO, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. ~~And so on~~.		The SETANGLEYAW_W command sets the yaw angle to 45°, and waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE commands set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait before each shot, and the total yaw angle range which shall be covered. The DOPANO commands finally run the pano sequence. The first DOPANO command, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. In each step the yaw axis is progressed by 90°/8 = 11.25°. Similarly for the next two DOPANAO commands.

OlliW: /* Running a Pano Sequence */

2016-03-05T22:36:16Z

Running a Pano Sequence

← Older revision		Revision as of 00:36, 6 March 2016
Line 179:		Line 179:
	STOP		STOP

	The SETANGLEYAW_W command sets the yaw angle to 30°, and waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE set some "global" parameters of the pano, namely the time to wait after each pitch ~~turn~~, the time to wait after each yaw step, the time to wait after each shot, and the yaw angle range which shall be covered. The DOPANO commands ~~when~~ finally ~~rum~~ the pano sequence. The first DOPANO sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. And so on.		The SETANGLEYAW_W command sets the yaw angle to 30°, and waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE set some "global" parameters of the pano, namely the time to wait after each pitch movement, the time to wait after each yaw step, the time to wait after each shot, and the total yaw angle range which shall be covered. The DOPANO commands finally run the pano sequence. The first DOPANO, e.g., sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. And so on.

OlliW: /* Running a Pano Sequence */

2016-03-05T22:35:01Z

Running a Pano Sequence

← Older revision		Revision as of 00:35, 6 March 2016
Line 179:		Line 179:
	STOP		STOP

	The SETANGLEYAW_W command sets the yaw angle to 30°, and ~~in additions~~ waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE set some "global" parameters of the pano, namely the time to wait after each pitch turn, the time to wait after each yaw step, the time to wait after each shot, and the yaw angle range which shall be covered. The DOPANO commands when finally rum the pano sequence. The first DOPANO sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. And so on.		The SETANGLEYAW_W command sets the yaw angle to 30°, and waits 3.0 secs in addition to the predicted time for the turn. The SETPANOWAITS and SETPANORANGE set some "global" parameters of the pano, namely the time to wait after each pitch turn, the time to wait after each yaw step, the time to wait after each shot, and the yaw angle range which shall be covered. The DOPANO commands when finally rum the pano sequence. The first DOPANO sets the pitch angle to 30°, and then does 8 yaw steps in counterclockwise direction. And so on.

OlliW: /* Running a Pano Sequence */

2016-03-05T22:34:43Z

Running a Pano Sequence

← Older revision		Revision as of 00:34, 6 March 2016
Line 165:		Line 165:
	=== Running a Pano Sequence ===		=== Running a Pano Sequence ===

	The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots~~. The following example you also find in the panao_v2.scr example file~~.		The previous motion control sequence allows to record a pano, which however is severely limited by the maximal possible script code size. Thus, more powerful commands were introduced, which allow quite extensive pano shots.

	CASE#DEFAULT		CASE#DEFAULT

OlliW at 22:34, 5 March 2016

2016-03-05T22:34:00Z

@@ Line 1: / Line 1: @@
-<span style="font-size:88%">''descriptions refer to firmware v0.77e and later</span>''
+<span style="font-size:88%">''descriptions refer to firmware v0.95e and later</span>''
 With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.
@@ Line 71: / Line 71: @@
   SETANGLEYAW angle(float, in degree°)
   SETANGLE pitchangle(float, in degree°) rollangle(float, in degree°) yawangle(float, in degree°)
   SETSTANDBY 0/1
   DOCAMERA 0/1/2/3/4
   DORECENTER
   SETPWM pwmvalue(int)
 == Examples ==
@@ Line 154: / Line 162: @@
 This short sequence consumes already 62 of the 128 bytes, which shows that only relatively short motion control sequences are possible with the on-board scripts.

OlliW at 09:07, 31 May 2015

2015-05-31T09:07:47Z

← Older revision		Revision as of 11:07, 31 May 2015
Line 1:		Line 1:
	<span style="font-size:88%">''descriptions refer to firmware v0.77e and later</span>''		<span style="font-size:88%">''descriptions refer to firmware v0.77e and later</span>''

	With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed ~~online~~, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.		With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed on-board, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.

	The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.		The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.

OlliW at 06:36, 17 May 2015

2015-05-17T06:36:56Z

← Older revision		Revision as of 08:36, 17 May 2015
Line 3:		Line 3:
	With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed online, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.		With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed online, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.

	The on-board scripts bring great possibilities, but ~~needs~~ some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.		The on-board scripts bring great possibilities, but need some understanding to avoid doing nonsense. This article gives some background, and presents the concepts by means of examples.

	== Overview of Script Types ==		== Overview of Script Types ==

OlliW at 09:12, 16 May 2015

2015-05-16T09:12:56Z

← Older revision		Revision as of 11:12, 16 May 2015
Line 1:		Line 1:
	<span style="font-size:88%">''descriptions refer to firmware v0.~~77a~~ and later</span>''		<span style="font-size:88%">''descriptions refer to firmware v0.77e and later</span>''

	With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed online, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.		With firmware version v0.51 the possibility of downloading scripts to the STorM32 controller, which are then executed online, without connection to a PC, has been introduced. It allows you to programmatically affect the behavior of the controller in order to achieve user specific needs and tasks with unprecedented flexibility. The STorM32 controller was the first of its kind to offer this innovative feature, which was when later adopted by others.

OlliW: /* Changing a Parameter via the Transmitter */

2015-05-16T07:35:38Z

Changing a Parameter via the Transmitter

← Older revision		Revision as of 09:35, 16 May 2015
Line 123:		Line 123:
	Of course, one is not limited to only the {{PARAMNAME\|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME\|Script Control}} parameters as discussed before), can be used in the SET and SETMINMAX commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).		Of course, one is not limited to only the {{PARAMNAME\|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME\|Script Control}} parameters as discussed before), can be used in the SET and SETMINMAX commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).

	Up to four cases can be distinguished, via the CASE#DEFAULT, CASE#1, CASE#2, CASE#3 statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME\|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [Inputs and Functions].		Up to four cases can be distinguished, via the CASE#DEFAULT, CASE#1, CASE#2, CASE#3 statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME\|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [[Inputs and Functions]].
	<!--		<!--
	This allows powerful possibilities, but obviously also allows to do stupid things. It's in the users responsibility to not do nonsense.-->		This allows powerful possibilities, but obviously also allows to do stupid things. It's in the users responsibility to not do nonsense.-->

OlliW: /* Changing a Parameter via the Transmitter */

2015-05-16T07:35:10Z

Changing a Parameter via the Transmitter

← Older revision		Revision as of 09:35, 16 May 2015
Line 93:		Line 93:
	STOP		STOP

	When the input specified in the {{PARAMNAME\|Script Control}} parameter field yields "default" value, then the pitch speed limit is set to 400 or 40.0 °/s, while ~~then~~ the input value is ~~that of case~~ #1 then the speed limit is set to 50 or 5.0 °/s. Every CASE statement needs to be ~~closed~~ with either a STOP or a REPEAT. Here the STOP commands is used, so that the preceding SET command is executed only once when the input value changes, and not every cycle again.		When the input specified in the {{PARAMNAME\|Script Control}} parameter field yields a "default" value, then the pitch speed limit is set to 400 or 40.0 °/s, respectively, while when the input value is such to trigger CASE#1, then the speed limit is set to 50 or 5.0 °/s. Every CASE statement needs to be finished with either a STOP or a REPEAT. Here the STOP commands is used, which means that the preceding SET command is executed only once when the input value changes, and not every cycle again.

	~~This way one can realize in total four different settings, as there are four cases CASE#DEFAULT, CASE#1, CASE#2, CASE#3.~~		At this point one may ask, which input values triggers which case? The full answer isn't trivial and needs a good familiarity with the STorM32 controller. In the given example, the default case is selected then the poti is below ca. 33% (< 1633 us), and case #1 is triggered then the switch is above ca. 83% (> 1830 us).

	At this point one ~~might~~ ask, which input values ~~correspond to~~ which ~~of the four cases, and at which position the poti has to be for a~~ case. The full answer isn't ~~short~~ and needs a good familiarity with the STorM32 controller. In the given example, the default case ~~would be~~ selected then the poti is below 0% (< ~~1500~~ us) and case #1 then the switch is at ca ~~100~~% (> 1830 us).

	'''''Method B'''''		'''''Method B'''''
Line 104:		Line 102:
	REPEAT		REPEAT

	The SETMINMAX ~~commands~~ linearly interpolates between the minimum value (50 or 5.0 °/s) and maximum value (400 or 40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (400-50)/1000 + (400+50)/2 = 295 or 29.5°/s. Hence, method B allows to adjust the speed limit continuously ~~within~~ the range of 5.0 °/s to 40.0 °/s. The REPEAT command at the end ensures, that the SETMINMAX command is ~~not~~ executed ~~only once~~, ~~but repeated again in the next~~ and ~~all following cycle~~, so that any change in the input value is quickly tracked.		The SETMINMAX command linearly interpolates between the minimum value (50 or 5.0 °/s) and maximum value (400 or 40.0 °/s), depending on the input value. For instance, for an input value of 200 the pitch speed limit is set to 200 * (400-50)/1000 + (400+50)/2 = 295 or 29.5°/s. Hence, method B allows us to adjust the speed limit continuously in the range of 5.0 °/s to 40.0 °/s. The REPEAT command at the end ensures, that the SETMINMAX command is executed at every cycle anew, and not just once, so that any change in the input value is quickly tracked.

	A video by GekoCH~~, which uses~~ this feature, is ~~found~~ [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].		A video by GekoCH using this feature is [http://www.rcgroups.com/forums/showpost.php?p=30246328&postcount=2723 here].

	'''''Method C'''''		'''''Method C'''''
Line 117:		Line 115:
	STOP		STOP

	This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the ~~respective~~ field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by ~~the GUI~~, and not in the ~~scripts~~. This issue is resolved by the RESTORE command, which sets the a parameter to the value stored in the EEPROM.		This example is essentially method A, but overcomes a minor yet potentially annoying issue. In method A, the parameter value specified in the {{PARAMVALUE\|Rc Pitch Speed Limit}} field of the GUI is overwritten immediately by the script, and hence becomes obsolete. In most cases one would however prefer that the default value is determined by this entry, and not in the script. This issue is resolved by the RESTORE command, which sets the {{PARAMVALUE\|Rc Pitch Speed Limit}} parameter to the value stored in the EEPROM.

	A similar RESTOREALL command exists, which sets all parameters to their ~~value~~ stored in the EPPROM. However, for efficiency reasons it should be used with outmost care and only if it is absolutely ~~needed~~. Using several RESTORE commands is preferred over using ~~one~~ RESTOREALL.		A similar RESTOREALL command exists, which sets all parameters to their values stored in the EPPROM. However, for efficiency reasons it should be used with outmost care and only if it is absolutely required. Using several RESTORE commands is much preferred over using RESTOREALL.

	'''''Concluding Remarks'''''		'''''Concluding Remarks'''''

	Of course, one is not limited to only the {{PARAMNAME\|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME\|Script Control}} parameters as discussed before), can be used in the SET and SETMINMAX commands and hence modified by the scripts. Furthermore, a case statement can of course be followed by more than one command, such that complex situations can be tackled.		Of course, one is not limited to only the {{PARAMNAME\|Rc Pitch Speed Limit}} parameter. ANY other available parameter (except of the {{PARAMNAME\|Script Control}} parameters as discussed before), can be used in the SET and SETMINMAX commands and hence be modified by the scripts. Furthermore, any case statement can of course be followed by more than one command, such that complex situations can be tackled (it is though not possible to have another case statement within a case statement).

			Up to four cases can be distinguished, via the CASE#DEFAULT, CASE#1, CASE#2, CASE#3 statements. A case is chosen dependent on the value of the input selected by the {{PARAMNAME\|Script Control}} parameter, in close analogy to all the other available functions such as the Rc Inputs, Pan Control or IR Camera Control, see also [Inputs and Functions].
	<!--		<!--
	This allows powerful possibilities, but obviously also allows to do stupid things. It's in the users responsibility to not do nonsense.-->		This allows powerful possibilities, but obviously also allows to do stupid things. It's in the users responsibility to not do nonsense.-->