Strange Behavior

[MrYsLab]

I have a Crickit hat for the Raspberry Pi and 2 dc motors connected. When I run the example programs, the dc motors run correctly. However, when I run the following program, one of the DC motors runs continuously. What am I doing wrong? BTW, I want to build a list of dictionary items that contain all the Cricket operations. I am trying to save a "reference" to the stepper function
(and ultimately for all cricket operations) for future use in my program.

I am using the latest version of Raspbian (full version) and Python3.

from adafruit_crickit import crickit
from adafruit_motor import stepper

z = {'crickit_object': crickit.stepper_motor.one_step,
     'modes': ['stepper'],
     'current_mode': None, 'enabled': False,
     }
print('done')

[ladyada]

hiya for tech support / coding questions please post in the forums - as its not a bug in the library or example code :)

[MrYsLab]

I believe that this issue should not have been closed, and is indeed a bug or at the very least an insidious side effect.

If you connect up dc motors to the motor pins and simply execute the following:

from adafruit_crickit import crickit
from adafruit_motor import stepper

reference_to_object = crickit.stepper_motor

One of the motors will start spinning. Since the library automagically creates instances of objects, when the crickit_stepper_motor object is created by the library, it should not energize the pins on the motor pins.

[ladyada]

you're activating a stepper motor - they work different than DC motors

[MrYsLab]

Yes I am aware that they operate differently. I am simply trying to get a reference to the stepper object. Power should not be applied to the coils until I actually give it an instruction to do so.

[ladyada]

kk i understand - you could try changing the stepper code init to not power the coils on init, see if that does what you want and submit a PR :)
https://github.com/adafruit/Adafruit_CircuitPython_Motor/blob/master/adafruit_motor/stepper.py#L73

[tannewt]

I don't think the pull request is the right solution because the default state of energized coils for a stepper motor is totally ok. Changing it for this one use of the Crickit library is inappropriate.

How a DC motor works when referencing the stepper_motor on Crickit is undefined behavior because it's only intended for use when a stepper motor is connected. If the behavior of this library is inadequate for use then one should use the lower level libraries directly.

@makermelissa This is a major change to how the library works and should have been a major version bump. Let's rollback the change in Motor and bump the major version.

[tannewt]

@MrYsLab I've reverted your PR but would like to help you achieve what you are trying to do.

So, why are you trying to build a list of all operations?

[MrYsLab]

@tannewt I am not trying to use the stepper object when I have a DC motor attached. The behavior was observed because I so happened to have a DC motor connected at the time. I am simply creating a data structure that contains references to all objects that the crickit supports for my code to use when required. I have built a GUI interface to test all the crickit functionality and do not know ahead of time what the user will connect. This interface will be also be used in a robot library that I am in the process of building.

If the crickit only supported steppers I would agree with your assessment, but since it is a "general purpose" interface, simply instantiating a stepper object should not cause the DC motor to spin.

If energizing the coils at instantiation time was essential for the operation of a stepper, I would agree with you, but since it is apparently not, I don't understand the reticence in removing coil energization at instantiation.

In my mind, if I must use the lower level libraries, there is no reason to use the crickit library and one of the reasons I purchased the crickit is because I believed it to provide a complete interface at the crickit library level.

[dhalbert]

Referencing an object provided by the Crickit library does initialization of that object: they're initialized on demand. The objects don't exist before they're used, as you know. So, for example, you can't have a reference to .servo_1 and .continuous_servo_1 at the same time, because they'd conflict. That's similarly true of the touch-related objects: if you reference a touch pin, then that pin is unavailable for use as GPIO. And when you first reference a touch pin, it's assumed that the pin is not being touched, and that's taken as a reference value to determine the touch threshold. So again, initialization happens.

This "create on first use" allows for a simpler API: simple programs end up being very short and easy to understand. But I can see it might not meet your needs for this particular demo. You could change your demo program so that the object wasn't referenced until a demo of that object was asked for, say by creating a variable that's None until needed, and then you assign the object. Perhaps you could restructure the UI in other ways to avoid premature instantiation.

[MrYsLab]

@dhalbert @ladyada Thank you for your reply. In the case of the touch pins, I beg to differ with you. If I enable signal1 and 2 as digital and signal 3, 4, and 5 as analog they all function as normal. After doing that if I read the touch pads, they still are functional. If you look at this youtube video, you can observe that I am enabling some signal inputs, demonstrate that their values change, then enable touch, demonstrate that the pads are working and if I go back to the signal they are still functional. If I first enable the touch pads and then the signal inputs, the behavior is the same.

As far as restructuring my program, of course that is possible, but it adds many more lines of code that create more potential for bugs and maintenance.

I am still baffled as to why this is a big deal. I need to move on - either I am going to publish my article using the Crickit for the Raspberry Pi if the change I requested is made, or if not, I will move on to another vendor's product. My preference is the Crickit, the choice is yours. All I ask is that you please let me know if my request will be honored or denied. Thanks.

[ladyada]

the overall question is whether stepper motors should be created and immediately activated. while i see both points, we have so far designed it when a stepper motor driver is initiated, the motor will 'hold' position. you can release the motor if you like, right after instantiation:

https://github.com/adafruit/Adafruit_CircuitPython_Motor/blob/master/adafruit_motor/stepper.py#L110

[MrYsLab]

@ladyada Thank you that was very helpful. Using "release" right after I establish a stepper reference solved the problem. Now I can move forward using the Crickit. Thanks again.

[ladyada]

gr8 - if you find any other bugs please open new issues