Hi Chris,
I’m trying out a new protocol on MWorks 0.7 (also wondering about 0.6) and was previously using a 0.5 nightly build. I realized that there are many more required attributes for a Generic IO Channel. Simply creating these attributes and not assigning values to them was not enough to stop the errors (see example below). So I am wondering if there is a set of “default” values I can assign to these because I don’t know what to set them to given that I have never used them.
Here’s what I had for the IO Channel before:
_id=“idm35183002561984”
_element_key=“Generic IO Channel”
type=“phidget”
tag=“channel1”
variable=“LickInput1”
index=“3”
capability=“analog_input”
And here is what I need to input now:
_id=“_id3”
_element_key=“Generic IO Channel”
tag=“channel”
variable=“”
capability=“”
data_type=“phidget”
direction=“”
synchrony=“”
range_min=“0”
range_max=“1000”
resolution=“”
update_interval=“3ms”
data_interval=“1ms”
I read in the help pages that “data_type” replaces “type” but direction, synchrony, range_min, range_max, resolution, update_interval and data_interval are all new and I’m not sure what to input (and whether Phidget Boards require certain values in those attributes).
I’m also wondering whether these will apply to 0.6 as well (what are the differences with 0.7) as I’m currently on the fence about which version to use.
Thanks for the help!
Javier
Example Error:
00:00:06: ERROR: Object is missing required attribute “range_max”
Extended information:
object_type: iochannel/phidget
ref_id: idm35183138906432
component: channel1
parser_context: mw_anonymous_create
Hey Chris,
Just an update. I tried debugging the protocol in MWorks 0.5 and got it working (bugs unrelated to this, just your typical things like named variables wrong some places, etc). I then tried it on MWorks 0.6 on a machine running El Capitan and it worked (albeit the Generic IO Channels handling the Phidget board have both “rate” and “sensitivity” attributes which I set to 0). I then tried running it on MWorks 0.6 on my laptop again (running Sierra) and now it mysteriously works.
In the process I also cleared out all my MWorks installations and reinstalled MWorks 0.6 clean. So I’m still not sure if it’s a problem with MWorks 0.7 but at least I know MWorks 0.6 on Sierra runs it fine.
It could also have something to do with the unrelated bugs I cleared out when debugging with MWorks 0.5 and nothing to do with the MWorks version…
Anyway, thanks again.
Best,
Javier
Hi Javier,
I read in the help pages that “data_type” replaces “type” but direction, synchrony, range_min, range_max, resolution, update_interval and data_interval are all new and I’m not sure what to input (and whether Phidget Boards require certain values in those attributes).
Presumably, the Phidget device isn’t using any of the missing parameters, so any valid values should be fine. Here are some defaults you can use:
- direction:
input
- synchrony:
hardware_timed_synchronous
- data_type:
analog
- Others:
0
Also, “data_type” does not replace “type”. In fact, I’d be surprised if the experiment even loaded without a “type”.
I then tried running it on MWorks 0.6 on my laptop again (running Sierra) and now it mysteriously works … So I’m still not sure if it’s a problem with MWorks 0.7 but at least I know MWorks 0.6 on Sierra runs it fine.
I think I’m missing some information here. Were you having problems with MWorks 0.7 and/or macOS Sierra that aren’t related to missing parameters?
Chris
Hey Chris,
I think I have a better idea of what’s going on. And I think it has to do with the Phidget plugin. Today I reinstalled MWorks for a separate reason but I forgot to add the Phidget plugin and when I tried running the protocol I ran into the same issues I described above (“missing attribute ‘data_interval’”…etc).
Once I placed the plugin in the plugin folder the errors changed to “unknown attribute ‘data_interval’”
Once I removed these extra attributes I had added, it ran smoothly. So basically, the plugin is the one deciding which attributes it needs and this may be wholly unrelated to which MWorks version I’m on. I still haven’t tested whether the protocol (+ the plugin) work on MWorks 0.7 but they do on 0.6.
Javier