@dc42 Solved. Will check later to see if I can measure what is happening on io7.in and i5.in on those 2 boars, to see if I can measure the values you told me to measure. SHpuld I create a new post or stay here with an update later?
Posts made by Tinchus
-
RE: Problem on io7.in
-
RE: Problem on io7.in
@dc42 thanks, I this this would be the last: if I use ou7.in for a swich and out.out for the other swith, both will share GRND, right. Any problem with that config?
In formware would be
M950 J4 C"!io7.in"
M950 J7 C"^io7.out"With this config something is wrong: I connect both switches and the status on the boject model changes. If I activate (manually) the switches, there is no response. Both switches are NC
-
RE: Problem on io7.in
@dc42 thanks , will chek that . As an alternative: I dont have any other free io.in pin, reading docs says I can have 32 gpin ports. Is that number taking into consideration the use of expansion board or I can transfor and .OUT pin into an .IN pin?
-
RE: Problem on io7.in
@T3P3Tony have a surprise jajajaja. Since I dont know what to measure on the board to check if the pin is faulty or not, I tried on another board, this one is a v1.02. This board has the same exact configuration and the sensor BUT io7.in was being used, so in this case I had io5.in free so I connected the sensor there... and it doesnt work, exactly the same failure like with the other board.
I modified the config in order to use io7.in... and the sensor works perfect.
I go again to the V1.01 board, change config to use io5.in... and works!
This is very strange!
Update: I have tested a third board, V1.01b, in this one io7.in is also failingIs there any value I can measure on the board or something ??
-
RE: shutting down a servo?
@droftarts I remember having tried that servo, I changed it just becauso of it torque (the futaba one is almost double). And the other important differentce is that your servo is analog, mine is digital
-
RE: shutting down a servo?
@jay_s_uk ok. My intentio is not to cut the power" but to achieve what in the documentatios is refered as away to avoid having the servo in a stall situation.
lets forget about the noise, if I execute m42 P0 S0 even if I have the noise I can trust no control signal is being sent to the servo? -
RE: shutting down a servo?
@droftarts Sorry, I missread. You meant M42 and I read M280 jajaja. Sorry again.
I intentionally moved the servo to a position that I know will create a stall situation. I can hear the buzzing sound on the servo. Then I executed M42 P0 S0, and the sound is still there and it is not possible to move the servo by hand, it is definitely having power and trying to reach the commanded position, so the M42 command seems to not have the effect Im looking for? -
RE: shutting down a servo?
@droftarts that was my understanding, yes. But as I posted above, reading the documentation again on the link provided, says "then use M280 P# S0 to stop commanding the servo"
To my understanding stop commanding meand stop sending command signal or something similar. An as stated on the documentation, that comand is an option in the case where the servo is may be neing prevented from reaching position, so the servo will start to draw a lot fo current. To avoid taht we can command the movement , and then send M280 P# S0.
Then the information on docuemntation might need to be updated/corrected?
Going back to my problem: any idea on how can I shut down the servo?
-
RE: variable to objects are pointers or something like that
@dc42 DSF Version: 3.4.6
Firmware: RepRapFirmware for Duet 3 MB6HC 3.4.6 -
shutting down a servo?
Hi. I have a small servo connected to a duet3 (3.4.6, SBC mode, the servo open and close a smal lid, it is a 9g style servo, specifications are ok for the duet3 board)
The servo is connected to its own 5V PSU (it uses 6.5 V ), just to avoid any potential problem of stall current or related things.Configuration on config.g:
M950 S0 C"io5.out" Q285
M280 P0 S1380The servo is a futaba SU-300. Acording to their tech support since it is a digital servo, the pwm frequenncy should be 285 and so I configured that on the M950 command
The M280 P0 S1380 moves the servo ok in one direction,, M280 P0 S1450 moves it on the other direction.
The problem is (may be it is not a problem jajajajaj): when I move the servo to M280 P0 S1450, the servo moves and then when it stops keeps doing a buzzing noise (small noise). Im guessiing, just guessing since electronics are not my field, that the noise comes is the servo trying to keep the position or maybe the servo is stall and trying to reach final position?
To test this following the instructions here: https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_servos, on the stall current section says:
Servos that are commanded beyond their movement limits usually stall. This heats up both the servo and the Duet. The servo is likely to burn out if held in this state. So:
Ensure that the Duet can supply the stall current. >>>> not my problem because Im using an independant power source for the servo?
Either be very careful not to command the servo beyond its working range, or else command the servo to move, hold it for a short time, then use M280 P# S0 to stop commanding the servo (replace # by the pin number or GpOut number as usual).I used the command M280 P0 S0 and the noise is still there, and the servo is still being commanded because if I try to move it I can feel the servo applying torque and keeping its position
Should the command M280 P0 S0 do this I mean "turn off" the servo"
Thanks in advance for the help
-
RE: variable to objects are pointers or something like that
@dc42 thanks for the info.I will test this onece back at the school.
What I dindn{t include on the post was all the "debugging" stuff I was using. This is what it is doing :
M25 >>>>>> do the pause, ok
set global.filament = {move.extruders[0].filament} >>>>> at this moment I can read on interface "ABS"
echo global.filament >>>>>> this shows me the value ABS, as expected, so till here the variable has the correct value
M702 S{global.filament} ; descarga filament actual >>>>>> this unloads the material.
M400 >>>>> not sure is needed, intention is to not continue with exewcution till all unload movements are doneM701 S{global.filament} >>>>>> here it is my problem, this global was assigned at the very start of the macro, the echo command confirmed me that the value was "ABS". So I was thinking the global was still having a value of "ABS". But it daesn´t . looking at the objects tree, I can see the global variable having a value of "".
It is like after executing the unload.g belonging to the filament loaded, the gloabl variable is updated? (just like a volatile declaration on C for example, or like a pointer?)
-
RE: variable to objects are pointers or something like that
@deckingman Sorry, just a typo on the post, the code is the one I pasted on top:
M25
set global.filament = {move.extruders[0].filament}
M702 S{global.filament}
M400
M701 S{global.filament} -
variable to objects are pointers or something like that
Hi. Im doing some macros. Im on a filament change macro, so in filament-change.g I have:
M25
set global.filament = {move.extruders[0].filament}
M702 S{global.filament} ; descarga filament actual
M400
M701 S{global.filament}My intention here is to react when the filament run out sensor triggers. So I unload the loeaded material and reload the same material , that is why I assign the name of tjhe material to a global variable.
This macro is working on the unload part, I have checked that initial global variable is done properly, but when M701 S{global.filamento} is executed I get and error saying Error: in file macro line 5: M701: non-empty string expectedSo looks like the global variable was updated like if it is a pinter to the object in memory.
Any way to work around this?Thanks in advance
-
RE: Problem on io7.in
@T3P3Tony thnaks for the quick answer. Changed to io6.in and it is working, unplugging the switch on i7.in shown no change on the object model value (it is showing always a value of "1")
Anything I can do to check on the board. Everything else on the board is working ok, this one in paricular has been working for 2 years aI think, it is just now that it came yo my mind use io7.in -
RE: Problem on io7.in
@T3P3Tony checked, it is ok. Looks like it is the board, i checked the same sensor on another board and it worked. I will check again the crimps... but could io7.in be damaged, io7.out works ok, it is just that pin. The one "failing# is a board 1.01, the one working ok is a board 1.02. I read docimentation to check if there is any difference, look like it doesn´t
-
Problem on io7.in
Hi. Im trying to use a normal switch, it is a normallly closed one. I have connected 1 of its pins to GND on IO7, and the other pin to IO7.IN
Config is:
M950 J4 C"io7.in"
M581 P4 T3 S1 R0I have triple checked, there in no other J4, P4 or any other ssignment pint to number 4, the same with the P4 assignment.
I manually activate / deactivate the swich and the board cant detect it. If I unplug the connector FROM the board, the status of the input changes ans it wopuld have been activated (I see it in the object model)
Ideas about what could be wrong?
-
RE: Error: G1/G2/G3: intermediate position outside machine limits
@T3P3Tony sounds perfect, since the warning is about something outside the print area but ahs no way of creating problems (something to work also from the slicer perspective I think)
Thanks!